-
Notifications
You must be signed in to change notification settings - Fork 56
ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (8th of April 2021)
CDR API Stream edited this page Dec 21, 2021
·
6 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
- Presentation
- Q&A
- Any other business
- 5 min will be allowed for participants to join the call.
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.
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 | 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 | 26th of March 2021 Edition | View in browser here |
| DSB Newsletter | 1st of April 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 | Decision Proposal 173 - Energy Draft Feedback Cycle 2 | Link to consultation |
| 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 |
| Action | Joint Account Guidance - is it finalised? | Link to CDR Support Portal - Finalised joint account implementation guidance |
| Workshop | OIDF & DSB - Introduction Workshop & the Consumer Data Standards | Register here |
| Workshop | OIDF & DSB - Technical Workshop & the Consumer Data Standards | Register here |
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 | Chantelle Demian |
| DSB | CX Standards | Michael Palmyre |
| DSB | Technical Standards - Banking | Mark Verstege |
| DSB | Technical Standards - Energy & Engineering | James Bligh |
No presentation this week.
Questions will be received by the community via WebEx chat before the questions are opened to the floor. Participants can pre-submit questions to the DSB mailing box.
We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #11096
| Ticket # | Question | Answer |
|---|---|---|
| 189 | I’m trying to ascertain when a Data Holder needs to create a policy. Do they need to create and make it available when they begin Product Reference Data sharing (i.e 1 October 2020 for the non-major banks), or only when they start sharing Customer Data (1 July 2021 for the non-majors). I’m assisting a couple of non-major banks in their compliance journey and have been unable to find anything definitive relating to when they need to have this policy published. |
Thanks for your query. As you are aware, Privacy Safeguard 1 (section 56ED of the Competition and Consumer Act 2010) requires a data holder of CDR data to have a CDR policy. We consider that this obligation currently applies to all data holders. This enables prospective consumers to understand how the data holder will handle their CDR data, as well as providing an explanation of the data holder’s voluntary product data request process, as required by CDR rule 7.2(3). As you note, much of the information required to be in a CDR policy relates to consumer data sharing. Where a data holder is not yet required to share any CDR data in response to an accredited data recipient request, the CDR policy may address the information requirements at a high-level and note that additional detail will be provided at a later date closer to when the data holder’s mandatory consumer data sharing obligations commence. Links to a data holder’s CDR Policy will also be required to be provided during the ACCC’s onboarding process. An absence of the CDR policy at this stage may impact a data holder’s ability to enter the CDR ecosystem and possibly jeopardize the data holder’s ability to meet their consumer data sharing obligations due on 1 July 2021. For guidance regarding the CDR policy, please see Chapter 1 (Privacy Safeguard 1) of the OAIC’s CDR Privacy Safeguard Guidelines and the OAIC’s Guide to developing a CDR policy. |
| 337 | Let us know whether all Data Holders have implemented Concurrent Consent. If not when are they bound to implement.? | The standards binding date for concurrent consent was 1st November 2020. Data holders are expected to implement the aspects of the standards related to concurrent consent by that date if also required by the phasing included in the rules. The only exception to this is where exemptions have been requested and granted. Exemptions can be viewed on the Exemptions Register. CDR Support Portal Article |
| 361 | Can you please clarify what is meant by clause 6.4(3) of Schedule 3? We are attempting to understand the return data set from our "non Get Product..." APIs for Phase 1 (we are a non-major and have a compliance date of 1st July for Part 4). Since only Phase 1 products are in scope for this deadline, we have interpreted this to mean: 1) A call to "Get Accounts" and "Get Account Details" will only return accounts which are based off a Phase 1 product. This has the follow on effect that calls to the following API endpoints will only be possible for Accounts returned from (1) above and hence only accounts based off Phase 1 products: - Get Bulk Balances - Get Balances for Specific Accounts - Get Account Balances - Get Transactions for Accounts - Get Transaction Detail - Get Direct Debits for Account - Get Bulk Direct Debits - Get Direct Debits for Specific Accounts - Get Scheduled Payments for Accounts - Get Scheduled Payments Bulk - Get Scheduled Payments for Specific Accounts Is this correct? I ask because the legal text in section 6.4(3) Schedule 3 is not written in a way which I can understand from a technical implementation view point. |
The effect of Schedule 3, Clause 6.4(3) for non-majors is that certain consumer data is not required to be disclosed as at 1 July 2021, when Phase 1 consumer data sharing goes live. The consumer data that isn't required to be disclosed at that time is set out in 6.4(3)(a) and (b). For non-majors, this data must be disclosed from 1 November 2021. CDR Support Portal |
| 420 | We are unsure as to whether a sole trader should be considered a 'person' or 'organisation' for customerUType. It seems we have to elect one or the other option. If we elect 'person', then we won't be able to display the business details e.g. abn, businessnName etc, which are also relevant for a sole trader. However the CDR Rules (Schedule 3, 1.3) indicate that "if the person operates a business" we are required to provide the business name, ABN, type of business etc etc. Can you please advise expectations for individuals operating a business via a sole trader structure. |
This is at the discretion of the data holder to determine in alignment with how the customer is represented in other digital channels. The most commonly used options available to the data holder are: - Treat the customer as an individual if this is how they are treated elsewhere (for instance a retail customer with a business account is still essentially treated as a retail customer). - Treat the customer as an agent of a business. - Under the CDR federation definition for customer offer the customer the choice as to whether they wish to use their personal or business profile during the authentication phase of the consent flow and then treat them for data sharing according to their election. CDR Support Portal |
| 591 | As an ADR (principal) coming through a provider (another ADR) request multiple concurrent consents for the same consumer with a single Data Holder? One of the Principals (ADR) is planning on obtaining multiple consents from the same consumer with a particular data holder to facilitate obtaining consent one for mortgage application (for a 3month period) and the other for the budgeting application (for a 12 month period). So having concurrent consents for a particular consumer with the same data holder is permitted? | Yes CDR Support Portal |
| 593 | To be able to record complaints made by CDR Participants, we would need to verify that the CDR Participant are in fact a CDR Participant - how will DH's be able to verify a CDR Participant when they make a complaint? Do we need to? Are there any scenarios where we would need to verify the CDR Participant in order to resolve their complaint?? | The recent amendments to rule 9.4 and the definition of ‘CDR complaint data’ in rule 1.7 mean that a CDR participant is no longer required to report to the ACCC and the OAIC on the number of complaints it receives from other CDR participants. The reporting forms will be updated in the near future to reflect these changes to rule 9.4 and the associated definitions, making clear that reporting on the number of complaints received by other CDR participants does not need to be included in these reports. The ACCC will communicate to stakeholders when the new form is available. CDR Support Portal |
| 676 | I have few questions regarding showing one-off consents on the consumer consent dashboard of the data holders. 1. Is it required to populate those consent details on the consent dashbord? 2. If yes, under which status we should list them down on the consent listing page? 3. Do we have any cx guideline to refer to on displaying one-off consents on the consumer dashboard? |
We've just published CX Artefacts for DH dashboards, you can find them here. See 'Single occasion disclosure' for relevant rules and guidelines on once-off consents. Responses to your questions below in bold: 1. Is it required to populate those consent details on the consent dashbord? DSB: Yes, assuming you mean the aspects referred to in the response to query 2 below. 2. If yes, under which status we should list them down on the consent listing page? DSB: Depending on the meaning of 'status', a single occasion disclosure could be listed: a. As 'active' if the duration is up to 24 hours (i.e. not 0 or absent) and that time period has not yet elapsed; or b. As 'expired' if the duration is 0, absent, or a period of up to 24 hours that has elapsed; and/or c. If 'status' refers to how to present the information specified in rules 1.15(3)(b),(c), (d) and (e), (i.e. the time-based qualities of the authorisation), then these can be displayed through a combination of points a and b (above) and in the 'sharing period' design component. 3. Do we have any cx guideline to refer to on displaying one-off consents on the consumer dashboard? DSB: Yes, see the link in the first line of this response. CDR Support Portal |
| 681 | Do we need to pass any authorization header during ADR revocation endpoint call? Can't see any specific requirements in ACCC documentation. | the call from the DH to the ADR required client authentication. The client assertion is sent in the body of the POST request. CDR Support Portal |
| 694 | 1) From User Experience perspective are there requirements for the below? - preselection of the accounts - displaying to consumer what the changes are in regards to this "amended consent" 2) Also when you say use the same consent flow, am assuming all the existing notification logic and also SMS OTP remain the same? 3) Any planned updated documentation in the technical standards (sequence diagram etc) and CX standards (screen mockups etc) to provide clarity on how this would work? |
1) Yes. DP 144 defines new requirements for amending consent: https://github.com/ConsumerDataStandardsAustralia/standards/issues/144. The approved decision https://github.com/ConsumerDataStandardsAustralia/standards/files/6262461/Decision.144.-.Amending.Consent.-.Authorisation.Flow.pdf) introduces a new standard that banks MAY implement from July and MUST implement from November this year. 2) Correct. 3) There are no technical standards documentation other than what was originally published. This includes detailed sequence diagrams available here: https://github.com/ConsumerDataStandardsAustralia/standards/issues/136. CX guidance is provided here: https://github.com/ConsumerDataStandardsAustralia/standards/issues/144 CDR Support Portal |
| 702 | The same set of payments can be established via call centre as directly via online banking, eg Immediate, delayed (scheduled) or regular payment/s to a BSB/Account payee or a BPay Biller. Those payments established by the call centre are never visible in the customer's online banking, while those payments established directly by the customer using online banking are visible and can be managed. In terms of the convention CDS-DC-0008, it comes down to whether the call centre is considered as an 'existing digital banking channel' or not. |
A contact centre isn't typically considered a digital banking channel. Whether these payments are treated as scheduled payments is at the discretion of the Data Holder and needs to be commensurate with how they are treated in the customer's existing digital banking channels. |
| 708 | Our Term Deposit products don't have a normal BSB and Account number like a transaction account would, they only have alphanumeric identifiers that are shown to the customer for reference in internet banking. Are these alphanumeric codes appropriate for sharing as the 'accountNumber' for a Term Deposit? Noting that the field is named '...Number' and the description for the field includes - "The unmasked account number for the account" and "Is expected to be formatted as digits only" Also nothing that the masked form is called -maskedNumber with the description being - "A masked version of the account. Whether BSB/Account Number, Credit Card PAN or another number" I know that the Type for all these fields is 'string' but wanted to check whether the internal alphanumeric identifier is actually useful/relevant in the schema for these cases. |
This is a thorny one. The expectation of the client using those fields is that they would be APCA numbers and would therefore be usable when populating a payment form for instance. The number field is optional because there are scenarios where the field can't be populated (like when the number is a PAN). The masked field on the other hand doesn't have a problem as it doesn't stipulate digits only. The actual treatment is at your discretion as long as the requirements of the schema are not invalidated. I would recommend, however, that you: - Populate the maskedNumber field with a masked version of your account number - Leave out the accountNumber field in the detail response |
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, We have undertaken a review of the CDR Support Portal as a channel for providing guidance on CDR Rules. Based on the volume and nature of questions we have received recently, we have decided to move to a model based on publishing guidance to the community, rather than providing individual responses to stakeholder questions. Our goal is to prioritise the provision of guidance that is accessible, transparent and has industry-wide application. We intend to develop this to meet clear community needs, which we will identify and prioritise based on questions and issues raised by stakeholders. We kindly ask for your patience as we work our way through the tickets, feedback and guidance
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 |