ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (25th of March 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (25th of March 2021)
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
Agenda
- Introductions
- Actions
- CDR Stream updates
- Presentation
- Q&A
- Any other business
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.
Updates
| Type | Topic | Update |
|---|---|---|
| Standards | Version 1.7.0 Published | Link to change log here |
| Maintenance | 6th Maintenance Iteration underway for 2021 | Read about the Maintenance Iteration - If you would like to join these please reach out to [email protected] |
| Maintenance | Decision Proposal 161 - Banking Maintenance Iteration 6 | Link to consultation |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| ACCC Newsletter | To subscribe to ACCC Newsletter | Link here |
| ACCC Newsletter | 3rd of March 2021 Edition | View in browser here |
| DSB Newsletter | 19th of March 2021 Edition | View in browser here |
| Consultations | Decision Proposal 160 - CX Standards This is a placeholder issue for consultation on CX Standards for non-individual consumers, business partnerships, and secondary users. This proposal is not yet ready for publication. This placeholder issue has been opened to gather initial community commentary on the scope and content of the proposal. While the intention is for this consultation to focus on the relevant items raised in Noting Paper 157*, the DSB encourages feedback on any additional CX Standards and CX Guidelines that the community views as required for the purposes of non-individual consumers, business partnerships, and secondary users. *Items 12-14. Item 16 on secondary user withdrawal standards will be dealt with separately. - Non-individual Consumers - Business Partnerships - Secondary users | Link to consultation |
| Consultation | Decision Proposal 162 - CX Standards, Joint Accounts, Authorisation Flow | Link to consultation |
| Consultation | Decision Proposal 164 - Endpoint Metrics | Link to consultation |
| Consultation | Decision Proposal 165 - Brand aware metrics | Link to consultation |
| Consultation | Decision Proposal 166 - CX metrics for Data Holders | Link to consultation |
| Consultation | Decision Proposal 167 - Direct to consumer | Link to consultation |
| Consultation | Decision Proposal 168 - Separate Consents, Authorisation Withdrawal | Link to consultation |
| Consultation | Noting Paper - White Label Conventions | Link to consultation |
| Consultation | Decision Proposal 173 - Energy Draft Feedback Cycle 2 | Link to consultation |
| CDR Support Portal | Support Portal Article on Brands in the Consumer Data Right Ecosystem | Link to Article on Brands in the Consumer Data Right Ecosystem |
| CDR Implementation Call | Administration - invitations will change by 1st of July 2021 | Awareness you will see the invitation change - we will use the existing invitation list |
| Consultations | Reminder - Decision Proposal 144 - Amending Consent & Authorisation Flow; reopened and closes tomorrow 26th of March 2021! | Link to the consultation here |
| Community | New Post from one of our regular contributors Manglu CDR Related articles - Looking for feedback and collaborators | Link to their community post here |
CDR Stream Updates
Provides a weekly update on the activities of each of the CDR streams and their workplaces
| Organisation | Stream | Member |
|---|---|---|
| ACCC | CDR Register (Technical) | Ivan Hosgood |
| ACCC | Onboarding | Wayne Solomon |
| DSB | CX Standards | Eunice Ching |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
Presentation
Presentation this week Ivan Hosgood from the ACCC and Mark Verstege from the Data Standards Body will walk through Scenarios 3, 4 and 5 in the latest Noting Paper - White Label Conventions and covered in the CDR Support Portal Guide "Brands in the Consumer Data Right Ecosystem".
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.
New Experiment for Q&A
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #11096
Answer provided
| Ticket # | Question | Answer |
|---|---|---|
| 362 | For Credit Cards, we assume that only the Owner of a Credit Card can share and view their data for that Credit Card and that Additional Cardholders would not be able to view or share data for the same Credit Card account as they are not considered to be owners of the liability and therefore should not be entitled to share that data. Example: I'm a Sole Trader with a small business credit card and I have 2 additional card holders that I also share my Credit Card Limit with. I as the sole trader (individual) will have the ability to view and share my data for this particular account. I would not expect that any additional card holder can view or share the data as it is my liability. Is this assumption correct? | Thank you for your query. As you know, we made amendments to the Rules in December 2020. We are answering your query on the basis of the amended rules. In your example, if the account holder is an individual (including a sole trader who holds the account as an individual), the secondary users rules mean that each additional card holder who is an eligible consumer (as defined in clause 2.1 of Schedule 3 of the rules) may be permitted to share CDR data relating to the account with accredited persons. This is possible where the account holder approves of them doing so by making a‘secondary user instruction' (rule 1.15) For other business consumers, such as non-individuals and business partnerships, the rules provide the ability to nominate individuals (nominated representatives) who are able to give, amend and manage authorisations to disclose CDR data on behalf of the business. CDR Support Portal |
| 364 | Per Decision proposal # 57, it is understood that where a data hold doesn't store direct debit authorization in a separate dataset , the information required by Get Direct Debit* and Get bulk Direct Debit API will need to be inferred from previously executed Direct debits. Question is how far back in time should a data holder need to go to scan for previously executed direct debits as direct debits could have half yearly, quarterly, or even annual frequencies. Also, previously executed direct debit records do not indicate if the direct debit authorization is still active. Direct debit authorizations is not something that we (MyState bank) display to our customers on digital channels, so if we are to return his information it will be handy to know if there are any guidelines on the time period to consider for previously executed direct debit authorizations and also if it will be appropriate to return once-off direct debits in response. As per the article; is method could mean that we may show direct debits that are no longer active. For example, a direct debit that occurs each month but had its last execution in the current month may be returned in the API for Direct Debits. The transaction history itself doesn't reflect if the direct debit is still ON or terminated. In such a case wouldn't the ADR interpret such a direct debit to be an active authorization? | CDR Support Portal Article That's correct - we would expect a data holder to provide information about authorisations such as direct debits, provided they fall within the scope of data required by the rules. This could include direct debits that are no longer active, as there is no relevant exclusion in the rules. CDR Support Portal |
| 375 | Does product reference data for all products from all phases need to be made available from 1 October 2020 if you are accredited? i.e. are the product reference data obligations different to mere data holders? | You are correct: PRD for all phases was required to be shared by accredited ADIs from 1 October 2020. This is reflected in the updated commencement table at Schedule 3, Clause 6.6 of the rules. The table now notes that at the 'start date' (i.e. 23 December 2020, the date on which the most recent rules amendment instrument commenced), accredited ADIs were already required to share PRD for all product phases. CDR Support Portal |
| 385 | Is a signatory on a business or retail account considered an authorised agent? I've attached (removed here) below a matrix of what a signatory is authorised to do on a business account vs an authorised office bearer. | Since you asked this question, the ACCC updated the CDR Rules. For business consumers, the rules require data holders to offer a service allowing consumers to nominate representatives who can authorise and manage disclosure of CDR data on behalf of the business (Rule 1.13). These rules are intended to be non-prescriptive, to enable data holders a degree of flexibility in implementation, for example by leveraging existing permissions processes. The rules do not currently have provisions directly relating to agents or attorneys on retail accounts. We are intending to provide guidance on this to stakeholders in due course. CDR Support Portal |
| 426 | What is DH obligations and its impacts re Vulnerable customers. | There are a number of provisions in the rules relating to data holders and their vulnerable or potentially vulnerable consumers. For example: rules, data holders are able to refuse to ask for an authorisation, or to disclose required consumer data, where they consider this to be necessary to prevent physical or financial harm or abuse (Rule 4.7) Data holders are also not required to update consumer dashboards for joint accounts where the data holder considers it necessary, in order to prevent physical or financial harm or abuse (Sch 3, Clause 4.14). This is not an exhaustive list, but the above examples may assist you in finding other relevant provisions in the rules. CDR Support Portal |
| 460 | The CDR Rules state that the CDR data environment means ‘the information technology systems used for, and processes that relate to, the management of CDR data’. Whereas the ‘CDR - Supplementary accreditation guidelines information security’ states that the boundaries of the CDR data environment ‘involves identifying the people, processes, technology and infrastructure that manages, secures, stores or otherwise interacts with CDR data,…may include infrastructure owned by, and management provided by, an outsourced service provider or third party’. The guidelines further state that an accredited person can limit the size of its CDR data environment through segregation of the environment from other systems. Schedule 2 Part 2 has a number of controls for end-user devices. If an end-user device is not directly connecting to the CDR data environment but instead a virtual desktop is being presented on the end-user device, e.g. AWS Amazon WorkSpaces, which is presenting CDR data, is the end-user device in scope for the CDR data environment and the Schedule 2 Part 2 controls? | One of the control objectives relating to end user devices is taking steps to secure network and systems within the CDR Data Environment. Relevant considerations for whether the end-user device may be in scope for the CDR Data Environment may include: - Whether CDR data being presented can be removed from the virtual desktop · To what extent can CDR data be seen/viewed/used via the virtual desktop environment If the end user device is in scope for the CDR Data Environment the schedule 2 controls will apply. CDR Support Portal |
| 601 | If an accredited intermediary creates a new infrastructure, e.g. a new AWS account, for each ADR that they are collecting data for, does each account need a penetration test performed on it to comply with the ‘Vulnerability Management’ requirement in Schedule 2 Part 2? It should be noted that each new ADR infrastructure is created from the same build template that has previously been assessed during penetration testing of other ADR infrastructure. | Whether a penetration test is required for each account will depend on the extent to which the new configuration is consistent with the build template. If it is built to the same design and consistent then it would be ok to rely on previous testing, subject to being within accepted testing/reporting time frames. However if each account has a different way of interacting with a data recipient, or data recipients have flexibility/freedom in configuring the build then depending on the way used it may introduce different vulnerabilities and will therefore require penetration testing. CDR Support Portal |
| 620 | We would like to seek clarification for the following topics: 1. Get Customer API - Expected payload for a Sole Trader - If a Person has both Personal and Business Accounts (as a Sole Trader), should the GetCustomer API only return "CommonOrganisation" data if the Business Account is part of the Arrangement? 2. Account numbers returned in the response, when the account number does not belong the consenting customer Example: accountNumber as described in BankingDomesticPayeeAccount, returned in the Get Scheduled Payment API or the BankingDomesticPayeeAccount (Get Payees API) As a dataholder, can we mask the accountNumbers for the payee or the counter party in the API responses, or is the requirement to return unmasked account numbers? | this depends on how you as the data holder represent sole traders. It should align with your existing treatment in existing digital channels. If you treat the customer as a business with an agent you should respond as an organisation. If you treat the customer as an individual you should respond as a person. Question 1. Get Customer API - Expected payload for a Sole Trader If a Person has both Personal and Business accounts (as a Sole Trader), should the GetCustomer API only return "CommonOrganisation" data if the Business Account is part of the Arrangement?[Answer] If the consumer is sharing personal accounts, then the personal customer details are shared. If the individual is sharing business accounts it would be the organisation details. If the individual has two separate profiles with the data holder under one identity, the data holder must show a profile selection step so that customers can choose what accounts to share. In this context (ie. which profile are they using post authentication, personal or business) the CDR Federation definition of Consumer could come into play. Question 2. Account numbers returned in the response, when the account number does not belong the consenting customer Example: accountNumber as described in BankingDomesticPayeeAccount, returned in the Get Scheduled Payment API or the BankingDomesticPayeeAccount (Get Payees API) As a dataholder, can we mask the accountNumbers for the payee or the counter party in the API responses, or is the requirement to return unmasked account numbers? [Answer] I might be misunderstanding this question, but if a consumer has consented to share their payee data with an ADR, this data must be shared in accordance with the standards. Credit Card PANs will be masked in payee data but not the account numbers of the payee. CDR Support Portal |
| 628 | 1. A DR can advertise its end points through software product during registration. This can be used by DH to find out the revoke end point. Considering this, does it have to be /arrangements/revoke? Can DR specify this as just /consent/revoke or any other subpath as long it is present in software product? 2. Can the documentation be updated to provide an example of DH calling DR for revoke? Came across this post https://cdr-support.zendesk.com/hc/en-us/articles/900004797823?input_string=revoke , but then it leads to an issue https://cdr-support.zendesk.com/hc/en-us/requests/327 which ends up in 404-NotFound. 4. Can you please let me know if rules at https://www.oaic.gov.au/consumer-data-right/cdr-privacy-safeguard-guidelines/chapter-12-privacy-safeguard-12-security-of-cdr-data-and-destruction-or-de-identification-of-redundant-cdr-data/ is the right place to look for CDR data deletion process? | Q: A DR can advertise its end points through software product during registration. This can be used by DH to find out the revoke end point. Considering this, does it have to be /arrangements/revoke? Can DR specify this as just /consent/revoke or any other subpath as long it is present in software product? A: As stated in my previous response, it has to /arrangements/revoke as defined explicitly in the standards. Otherwise data holders will have no idea how to call it. The dynamic registration process allows for the ADR to tell the DH the value of RecipientBaseUri but there is no mechanism for the ADR to tell the DH the full path. Previously a revocation_uri field was included in dynamic registration which could be used to define a full path for the revocation end point. We have now moved to a based path model instead of specific paths as there will be lower impact in the future if new end points are required as part of the ADR implementation. Q: Can the documentation be updated to provide an example of DH calling DR for revoke? Came across this post https://cdr-support.zendesk.com/hc/en-us/articles/900004797823?input_string=revoke , but then it leads to an issue https://cdr-support.zendesk.com/hc/en-us/requests/327 which ends up in 404-NotFound. A: There is a non-normative example in the standards for a call to the arrangements end point in the InfoSec End Points section. Q: Can you please let me know if rules at https://www.oaic.gov.au/consumer-data-right/cdr-privacy-safeguard-guidelines/chapter-12-privacy-safeguard-12-security-of-cdr-data-and-destruction-or-de-identification-of-redundant-cdr-data/ is the right place to look for CDR data deletion process? A: OAIC provides helpful guidance at this location but you should also refer to the CDR Rules published by the ACCC as they also give specific requirements for the privacy safeguards including deletion. CDR Support Portal - Using an arbitrary end point URI CDR Support Portal - CDR data deletion process |
| 638 | Where a customer creates a payment to a payee via a channel other than online banking - eg call centre - and that payee is not ever reflected in the customer's payee list in online banking, is that payee in scope for CDR? | We assume this question relates to whether such a payee must be returned via the Get Payees and Get Payee Detail endpoints. These endpoints are designed to return registered payees that the consumer has explicitly registered for repeated payments. Some ADIs call this an address book or registered payees. It is not expected to return all payees that have ever been paid to. Only those payees the customer has requested to be retained for future use. CDR Support Portal |
| 644 | Trying to see what the Rules/Specs says for a few error scenario(s) Let's suse this following 3 ADR software products that are registerd with a Data Holder (DH) GoodMoney - ClientID - CID001 GreatMoney - ClientID - CID002 ExcellentMoney - ClientID - CID003 Using simple clientIDs to communicate teh query (and not suggestin that Client IDs follow this convention in our solution) Scenario 1: Good request - asking for my own Information if GoodMoney makes a DCR GET request to GET /register/CID001 the Data Holder returns a 200 and things are all good. Scenario 2: Bad Request - Asking for a non-existent Client ID if GoodMoney makes a request to GET /register/CID999 What is the expected HTTP Status code? My interpretation is that a 403 is returned (this Client ID is not in the list of Client ID that is accessible to GoodMoney) Scenario 3: Bad Request - Asking for info about an existing Client ID that is NOT accessible to me if GoodMoney makes a request to GET /register/CID002 or GET /register/CID003 What is the expected HTTP Status code? My interpretation is that a 403 is returned (same reason as Scenario 2 as i am allowed to only view data related to Client ID CID001 Speaking to our product vendor , they are suggesting to return a 404 to provide better security (to not let requesters challenge random cliend id's and check if they exists in the system) What have the others (particularly the big 4) implemented so far? Is it considered compliant if a Data Holder returns a 401, 403 or 404 for Scenarios 2 and 3? Does the CTS test suite have a test case for this scneario? If yes, what does it expect? Looking for some guidance in this space. | The standards defer to the normative standard provided by OIDF for dynamic registration and the DSB do not provide specific guidance on the implementation of the normative standards as this guidance could run counter to pre-existing vendor solutions. Regarding the CTS suite tests please refer to the documents here. These documents contain information on what the CTS will specifically test. |
| 647 | Subject: Implications of temporary or permanent access revocation of consumer’s primary digital channel (IB) on active consents In terms of aligning the CDR consumer experience to the Data holder’s primary digital channel (which in this case is Internet banking), Do Data holders have to suspend consents AND/OR deny CDR requests from ADRs when the customer’s Internet banking access is temporarily suspended/locked (in scenarios such as ongoing fraud investigation). This also means that the customer will no longer have access to their dashboard to manage their consents with the DH. Do Data holders have to revoke/expire consents when the customer’s Internet banking access has been revoked/cancelled permanently (i.e. customer no longer has access to IB), again in scenarios such as confirmed fraudulent activity.Also, to ask this question in a slightly different manner; In the above 2 scenarios and when there is an active consent already in place, would the CDR consumer still be considered ‘eligible’ for CDR (as per Rules Schedule 3 - Part 2.1) in the instance where their access to internet banking is temporarily suspended OR permanently cancelled, and in any case, cannot access (any of) their accounts online temporarily or permanently? | There is no specific guidance provided for these scenarios. Certainly, a temporary suspension would not automatically require consents to be revoked or for data sharing to stop. In some cases, for instance, suspension of browser access to internet banking may not result in suspension of mobile access. In the same way suspension of internet banking would not constitute a suspension of CDR. In essence, however, this is an area that is left to the discretion of the data holder as the response needs to be contextual both to the type of fraud that has led to suspension and the level of risk that the customer is exposed to. CDR Support Portal |
| 652 | Should data holders allow new authorisations or amending of existing authorisations if a data recipient's accreditations is suspended or their software product is inactive? | No. The only actions permitted while a software product is inactive due to Suspension of an ADR is to 'Facilitate consent (authorisation) withdrawal'. Permitted actions are described in the CDR Register Design Reference in the Data Holder Responsibilities section. This article, What is the difference between 'Withdrawing' and 'Invalidating' consent for an ADR with the status of Suspended and Inactive?, explains further. |
| 662 | Our system has Interest Only payments (for example for loans or credit cards) as being event driven, is that the intent of BankingSchedulePaymentRecurrenceEventBased? | the event based recurrence indicates that the schedule of payments is defined according to an external event that cannot be predetermined. If the payment's schedule can be pre-determined (e.g. a loan deduction on the 5th day of every month), then it would be suitable to use the recurring interval schedule recurrence type. How an individual bank determines this should be in line with how your customers see this in their existing digital banking channels. The following convention may also be useful: https://cdr-support.zendesk.com/hc/en-us/articles/900004231103-Scheduled-payment CDR Support Portal |
| 665 | The test cases specified for phase 1 has executed by column with (DH/DR). As a data holder can I select only executed by DH in order to test the solution before commencing CTS. | The Phase 1 tests were executed manually in a coordinated industry test effort so there is no direct mapping between those and the CTS Test Scenarios. The manually executed scenarios were structured differently to those that can be executed using an automated tool. As you suggest selecting tests to be executed by a DH and executing these in your own test effort before CTS will give you good coverage. We recommend you: · Review Section 4 of the CDR Participant Test Strategy as it discusses the way in which Phase 1 and 2 scenarios can be used as example tests to support a participants test efforts. · Review the CTS test scenarios available on the CDR Support Portal Updated list of CTS test scenarios |
| 667 | We would like to understand what is the expected API response for when a DH receives a bulk API call that is a POST and includes multiple accountIDs and one more of then are blocked/no longer eligible (assuming it was previously associated with a consent)? Should the call be successful and data for the blocked/ineligible accoundIDs not shared or should the call be rejected? If data for the accountIDs in question is omitted from a 200 response that includes data for other accountIDs, is this a reportable refusal to disclose? | the DH should respond with a 422 error response specifying the list of accounts that will not be serviced. The ADR may then request the bulk API response excluding the accounts that are not shareable. CDR Support Portal |
Response pending
Updating the table below - if your question/ ticket has not received a response yet the team continues to work on a response. We do apologise for the delay on some tickets, the teams are doing their best to get to everyone's questions.
To our valued CDR participants, In light of the movement of the Rules function to the Treasury, we are assessing the current support structure and requests open on the CDR Support Portal. We kindly ask for your patience as we work our way through the tickets and support model; we will endeavour to get back to you as soon as possible. Thank you for your support.
Useful Links
A work in progress - open for feedback from the community on what you would like to see.
| Organisation | Description | Link |
|---|---|---|
| OAIC | Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right | Link |
| DSB | CX Artefacts - The CX Guidelines provide optional examples of key requirements and recommendations to help organisations build best practice consent models. CDR Participants should also refer to the CDR Rules, data standards, and privacy guidelines for a complete view of obligations to facilitate compliance. | Link |
| DSB | Consumer Data Standards Main Page - About the DSB team, engaging with our consultations and Events | Link |
| DSB | The Consumer Data Standards - The technical and consumer experience standards for the Consumer Data Right | Link |
| DSB | The Banking Product Comparator - a demonstration of Product Reference Data from Data Holders as part of the Consumer Data Right | Link |
| DSB | GitHub Consultations - all public consultations from the Data Standards Body | Link |
| DSB | Java Artefacts - An Open Source Project comprised of reference implementations of both Data Holders and Data Recipients | Link |
| ACCC & DSB | The Consumer Data Right Support Portal Knowledge base for the Consumer Data Right covering Rules through to Technical articles and questions | Link |
| ACCC | ACCC Main focus area/ landing page for the Consumer Data Right | Link |
| ACCC | GitHub Consultations - all public consultations from the ACCC Register Team | Link |
| ACCC | CDR Register Design Reference | Link |
| ACCC | Public page for the Consumer Data Right | Link |
| ACCC | Participant Portal page including sign-up and log-in | Link |
| TSY | Consumer Data Right background and historic records from the Treasury | Link |