Skip to content

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (10th of September 2020)

Jump to bottom
CDR API Stream edited this page Sep 10, 2020 · 17 revisions

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (10th of September 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.

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
Maintenance Banking Maintenance Iteration 04 Link to Summary
Link to Board of changes
Maintenance Retrospective held 2nd of September Link to board here
Maintenance 5th Maintenance Iteration is planned to commence on the 16th of September 2020 Updates and invitations will be notified to the broader CDR Groups later
Standards Version 1.4.0 Approved! Approved list of changes is located here
Event - Workshop DSB - Amending Consent Workshop
held on the 8th of September 2020		 Post Workshop Page here

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

No Presentation 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.

Current received pre-submitted questions:

Ticket # Question Answer
- Review of the following issues: 134, 135, 136, 137 & 140 -
142 What is the process for communicating when a planned outage will occur and what is the 'advanced notice' timing. Where can I find this documented? -
141 When will the decision 135 be reflected in the standards? We understand it will be in the next release. Do we have an ETA for when that update will be released? We feel it is difficult to fully understand the net impact (items added, removed or changed) of the decision until the standards reflect the decision holistically. -
140 CommonSimpleAddress schema - state field (mandatory) – If DH have data quality issues for some records for this field, can DH send free text (even if country is Australia) with the value as-is or should we send empty string "" for this mandatory field in this scenario -
139 I have a question about what is required with respect to what must be presented to the consumer in the DH dashboard relating to disclosure on a consent. The rules (1.15 (3) (f)) state:
information relating to CDR data that was disclosed pursuant to the authorisation (see rule 7.9);
This does not provide any detail on what “information” is required.
In the CX guidelines (pg 109) there is a picture of the consumer dashboard with the “guideline” 2 stating:
Data holder consumer dashboards SHOULD show details of any historical CDR data that was disclosed.
The example does not actually provide much information on the data that has been disclosed under the consent, how many times, when etc: it states only when data was first disclosed. Other information relates to the consent duration and the first holder date, but not to data actually disclosed.
Our question is whether it is sufficient to do as the example in the CX Guidelines has done (ie whether this example is compliant)?		 -
138 1) If DH do not hold country code (optional), area code (conditional), number (mandatory) in separate fields and only hold a phone number (which may or may not contain all the required splits), what is the expectation of the DH to provide in these fields?
For context, some scenarios of the types of data that exist in our backend system within the same field - 0396001234, 96001234, 9600 1234, +61396001234, +61401000123, 0401000123
2) CommonPhoneNumber schema - number field (mandatory) - How does this field vary from fullNumber field. Can DH provide a phone number AS-IS in DH back-end systems without additional formatting.
For context, some scenarios of the types of data that exist in our backend system within the same field - 0396001234, 96001234, 9600 1234, +61396001234, +61401000123, 0401000123
3) CommonPhoneNumber schema - fullNumber field (mandatory) - Are DH expected to provide a phone number in this field ONLY if we have the fully formatted phone number which incorporates country code, area code, number and extension? OR can DH provide a phone number such as some of the examples outlined above in this field? For context, we have numerous customer records with numbers stored without all the parts required to make it a 'fully formatted' number.		 -
137 Could we have an update on the status for the rules around Combined Accredited Person (CAP) arrangements -
107 If the Core Banking vendor/provider delivers Account Aggregation solution, providing technology for consent management and data capturing, does vendor have to become ADR? Where does responsibility to be compliant with CDR Rules sit: ADI or Vendor? The assumption is that ADI in this case should become ADR anyway.
If third-party provides to ADR solution on the non-exclusive SaaS licence basis, which includes CDR data collection, and solution is cloud-based, should the systems and data storage sit in the ADR cloud account (AWS or Azure) or this is acceptable when solution deployed in the third-party cloud account? The service will be provided from the ADR name, and third-party delivers technology only.		 -
106 Given the recent ACCC consultation to industry on intermediary use cases and future consultation on tiered accreditation, ADR’s disclosing data to professional advisers and CDR extending to business and corporate consumers - when is it intended that the final rules encompassing the consultations be published? The ACCC is currently finalising the rule consulted on recently and plans to send to the Treasurer shortly for his consent, before the ACCC can make the rule. For the future consultation, the ACCC plans to consult on these towards the end of September.
105 Follow-up on Issue 296 The Data Standards Body and ACCC are working through this issue; hence no clear response as of yet.
104 At last week’s weekly CDR call, I raised a query about the process for submitting the bi-annual reports to OAIC. I think you were going to pop a question on the page and confirmation of the OAIC email address for receiving the reports? Just wondering where this is at please, as we are seeking the information to finalise reporting procedures. CDR Support Portal
103 Is it valid to block requests from outside Australia or to block requests from specific countries that are flagged as high risk? If so, do these blocked requests need to be included in "refusal to disclose" statistics? There is nothing in the rules or standards that prohibit requests from outside of Australia so it would not be valid for a data holder to universally block traffic from non-Australian IPs that are otherwise compliant with the Information Security Profile. This is also applicable to scenarios where the customer IP address (passed as a header in attended scenario) is non-Australian.
That said, it is understood that traffic originating from certain locations may be an indicator of risk for a specific session or API call. Combined with other risk factors this may result in the need to block traffic. This is the purpose of the rules and standards accommodations for refusal of otherwise valid CDR requests. All such refusals are, however, required to be included in the refusal statistics.
102 Could you please clarify the expectations of the data required to be provided in relation to rule 9.5 as a data holder.
For 9.3(d) disclosures of CDR data made in response to consumer data requests; does this mean details of the response ie: to which ADR, date of disclosure, and data type within that consent contract, OR does it mean a entire list of all the data disclosed within the response?
For 9.3 (f) (f) CDR complaint data. Please provide some examples of the type of information required here.
Also, please confirm the intent of this rule, is to support customer to retrieve this data above and beyond the information provided in the Consumer dashboard or is the Consumer dashboard the solution to this rule?

The intention of rule 9.5 is to enable CDR consumers to access copies of records relating to particular information that is held and maintained by data holders and ADRs as it relates to their activities as CDR consumers. The requirements of rule 9.5 are separate to the requirements to provide specific information to the CDR consumer via the consumer dashboard.

Regarding the expectations for record keeping for the purposes of rule 9.3(1)(d), we note that paragraph 278 of the Explanatory Statement for the rules states that the record keeping requirements do not include a requirement to keep a copy or copies of collected CDR data itself. Rather, it is expected that data holders maintain ‘disclosure logs’ evidencing the type of CDR data that was disclosed, when the CDR data was disclosed (including time and date) and the relevant ADR the CDR data was disclosed to.

‘CDR complaint data’ is a defined term for the purposes of the rules (see rule 1.7). The definition includes the number of CDR consumer complaints received by the CDR participant, the number of such complaints resolved and the average number of days taken to resolve CDR consumer complaints through internal dispute resolution, amongst other things. For the purposes of rule 9.3(1)(f), data holders must keep and maintain records that record and explain their CDR complaint data. This could be in the form of ‘complaint logs’ which evidences information such as the following: name of the CDR consumer complainant; time/date complaint was made; complaint type; summary of the complaint; status summary of the complaint, including whether it was referred to an internal or external dispute resolution scheme, and if so, when; and if it was resolved, when it was resolved and a summary of the resolution outcome.

We also wish to note that, in line with the Explanatory Statement, records kept for the purposes of rule 9.3 should only contain personal information where it is necessary to comply with the rules.
101 I want to clarify how a DH should respond in the instance when no x-min-v header is submitted. ex: The max supported version by a DH is 2 DR sends a request with x-v 3. Should the DH respond with a 406 error message or else respond with the maximum version they support? In this case v2. CDR Support Portal
100 Can you please review scenario 4 in your Joint Account Guidance document? Why in the "ACCC implementation expectations" column in point (b) is sharing not allowed on Account 3?
I understand that sharing is not allowed on Account A and Account 2.
Account A cannot be shared because Mary withdrew her JAM election for Account A.
Account 2 cannot be shared because Mary withdrew her JAM election for Account 2.
However, as far as I can tell all required JAM elections are still in place for Account 3 from both Mary and John. In addition to this an Authorisation is still active for Account 3 from John.
I would assume that sharing is still available from Account 3 given this scenario, however you have stated that the DH should not share data for Account 3. Can you please explain this?
My simple take on the rules is that for data to be shared from a Joint account, the following must happen:
1. All joint account owners must have a valid 'election' for the joint account i.e., they must have agreed for that account to participate in the Open Banking ecosystem
2. A valid authorisation must exist for the account i.e., at lease one of the account owners must have consented to a sharing agreement (authorisation) with an ADR for that account
If an account is elected and a valid authorisation exists, then the data sharing arrangement can proceed. Is that correct?		 -
98 We are interested in implementing the capability to blacklist an ADR. This would be in order to protect customers and the regime in cases where an ADR is known to be behaving contrary to the ACCC rules, in advance of an ACCC response (via registry status change). Curious to know if the ACCC thinks this is in line with 4.7 (1) (b) (ii) or has any other comment/advice on the topic (ie has had discussions with other participants on this matter).. Taken on notice
97

In the CX Guidelines for the Dataholder consent management dashboard, there is a requirement to indicate the date when data was first exposed by (relevant section below). This information is presented at a data cluster level. For the situation where information in a data cluster has not yet been shared, what is the recommended approach for the dashboard. Should this section be removed or should it be altered to indicate that data in this cluster has not yet been shared?

CDR Rule 1. For subsection 56EM(1) of the Act, a data holder that discloses CDR data to an accredited person as a result of a consumer data request must, as soon as practicable, update each consumer dashboard that relates to the request to indicate: (a) what CDR data was disclosed; and (b) when the CDR data was disclosed*; and (c) the accredited data recipient. *For ongoing data sharing: Data holders should include the date range between which CDR data will be disclosed (dates of initial and final disclosure). For single or ‘once-off’ disclosure: Data holders should include the date on which the CDR data was disclosed (date of initial disclosure).

Consumer Experience Team response: If the data hasn't been disclosed then the notification doesn't need to be shown. When the data is disclosed that section can be added, and it doesn't have to be done in the way the CX Guidelines suggest - the DH can notify the consumer via the dashboard in another way.
91 Is there a timeline for (banking) data holder's direct request service standards? -
84 We have a query regarding versioning related to ‘Get Products’ and ‘Get Products Detail’ API. We have already developed the Version1 (v1) and we notice the current version is v3.
https://consumerdatastandardsaustralia.github.io/standards/#get-products
    Our queries are:
  1. Whether v1 (which is obsolete now) can be implemented to any new client (Banks in our case) or only the latest version (currently v3) should be implemented?
  2. For clients where already v1 is implemented and live, can they continue with that?
CDR Support Articles here and here
81 Is there a timeline associated with “outsourced service providers“ (OSP)? The CDR Rules currently allow an Accredited Data Recipient to disclose CDR data to an OSP under a CDR outsourcing arrangement. However, the CDR Rules do not currently allow an ADR to use an OSP to collect CDR data from a data holder. The ACCC recognises the importance of rules accommodating the use of third parties to collect CDR data from data holders on behalf of ADRs and has been developing rules that authorise third parties who are accredited at the ‘unrestricted’ level to collect CDR data on behalf of another ADR.
80 We are unable to add/ remove users from the portal. Is this a bug or is the functionality unavailable at the moment? User has been contacted for more information, CDR Team is waiting for response.
71

When you have a moment, would you be able to please share the process for registering as a data holder?

We are seeking clarity on the process to add our organisation as a Data Holder to this page: https://www.cdr.gov.au/find-a-provider

Taken on notice
70

As an ADR, we have sought consent from our customer to collect data from a Data Holder for a purpose, for example, "to provide accounting and taxation services.". The consumer has given consent for all data scopes for 12 months, and the Data Holder is honouring that consent, i.e. they had no reason to reject consent.

The consumer is utilising our ADR solution without issue or compliant to undertake their bookkeeping requirements. Our solution is cloud-based, and the consumer wishes to get assistance from qualified experts like an accountant, tax agent and auditor to meet quarterly GST reporting requirement, annual income tax return and audited financial statements. These experts are external parties directly contracted by the consumer to perform functions, and these experts have the proper professional qualifications (with associated insurance, indemnities, etc.). These experts are given a login to our cloud-based solution by the consumer, this login allows them access to all data within our solution. As the ADR we allow our users to provide logins to any party they deem necessary.

Question 1: As an ADR does the ACCC/DSB, believe we are in breach of any CDR rules by allowing our customers the ability to give access to adequately qualified professionals?

Question 2: Further to the above question does the ACCC/DSB believe we, the ADR is in breach of any CDR rules if these experts use derived CDR data from our solution in order to undertake tasks which are included in the purpose of consent for example lodge a BAS, prepare an Income Tax Return, prepare a set of Financial Accounts, provide those financial accounts to the Bank? (because that may be a lending requirement of the Bank)

We ask these questions because as an ADR, we are not allowed to share CDR data with a non-accredited party. However, we have not shared the data; rather, the consumer has allowed other parties access to the data and its derivations utilising our solution.

Questions 3 & 4: Does the answer to question 1 & 2 change if these experts utilise their own software tools? For example, an accountant uses a separate solution (not an ADR) to prepare a properly formatted set of financial statements in accordance with the Australian Accounting Standards. The accountant sourced their primary data from our (ADR) solution (this may have been done by manual data input, downloading summarised data or an electronic connection).

 Taken on notice
69

We are interested in the scenario where there is a valid consent with three associated accounts. If there is a reason not to disclose data relating to one of those accounts (as per 4.7) and data is requested for all three accounts we will still return data on an ADR request for data relating to the three accounts (for the other two accounts). The API response code will be a 200 (ie success). Is this request to be considered as a refusal as per reporting form section 4.1?

In the same scenario as above, but with a reasons not to disclose on two of the three accounts and each a different reason, please confirm that this constitutes a count of two times we have refused to disclose data as per 4.1 (one for each reason) even though the overall request is met with a success response?

 In response to your question regarding rejections. A rejection is an active decision not to present data for a valid CDR Request that has been appropriately authorised by the customer. In this context both scenarios would be considered a valid rejection. In the second scenario (where there are two blocked accounts) this should only be 1 rejection. The rejection could should be aligned to the number of invocations. This means that a call to get a list of accounts with two blocked accounts should be counted as a rejection but a second call to the same API would be a second rejection.
68 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?		 -

Notes

  • TBA

Question and answers

# Question Answer/ Action
#
#
#
#
#
#
#

Other business

  • TBA

Appendices

  • TBA

Next Steps

  • TBA

Getting Started

Meetings

Maintenance Iterations

CDR Implementation Call

Clone this wiki locally