ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 7th of October 2021 - ConsumerDataStandardsAustralia/standards GitHub Wiki

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEDT (Updated as per Issue 410 ) Location: WebEx, quick dial +61-2-9338-2221,,1650705270##

Meeting Details:

Desktop or Mobile Devices https://treasuryau.webex.com/treasuryau/j.php?MTID=m9614a7c6166155d3d950a8999e437f9f 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. Presentation
  5. Q&A
  6. 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
Rules V3 Rules Amendment Link to announcement
Standards Version 1.11.1 Published Link to change log here
Standards Next Version not scheduled V1.12.0 is proposed with some scope added: Consumer Data Standards V1.12.0 Project Board
Maintenance 9th Maintenance Iteration Agenda from the 6th of October 2021 meet
Maintenance Decision Proposal 212 - Banking Maintenance Iteration 9 Link to consultation
Maintenance 9th Maintenance Iteration Meeting Details Now included on Decision Proposal here
DSB Newsletter To subscribe to DSB Newsletter Link here
TSY Newsletter To subscribe to TSY Newsletter Link here
TSY Newsletter 1st of October 2021 View in browser here
DSB Newsletter 24th of September 2021 View in browser here
DSB Newsletter 1st of October 2021 View in browser here
Consultation Decision Proposal 197 - Candidate Account End Points Link to consultation
Consultation Decision Proposal 198 - Candidate Billing & Invoicing End Points Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 213 - CX Standards & Energy Data Language Link to consultation
Decision Made Decision Proposal 193 - Energy Non-functional Requirement Link to comment and attached Decision
Decision Made Decision Proposal 194 - Candidate NMI Standing Data End Points Link to comment and attached Decision
Community Quill Peak Consulting: CDR use-case development state pulse check report released Link to CDR Support Portal Community Post

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 CTS Andrea Gibney - Away this week
ACCC Onboarding Christine Atkins
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

Presentation

None 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.

We are trialling Sli.do for Question and Answer. Join our Q&A live here: https://www.sli.do/ Code: #169517

Answer provided

Ticket # Question Answer
922 this is a follow up question on question 913 answered in the Implementation call earlier today, Question 2: If the Dh must accept a combinations of scopes, Profile and accounts for example (no customer included) how should the authorization UI reflect this? And how should profile data sharing requests be responded to? Should the DH accept this combination of scopes but refuse customer data sharing is a customer scope is not included in the authorisation as well? While ADRs should not request Profile data without a customer scope as well, this cannot be enforced and the DH ultimately has the responsibility to not share customer data if the customer has not consented to it. By way of update, we're developing a decision proposal in response to this, and issue 404. A placeholder has been made in DP216 and the DP will be published soon: https://github.com/ConsumerDataStandardsAustralia/standards/issues/216
1076 Can you confirm if a Customer Service Centre is able to change the customer disclosure option from "Non-disclosure" to "pre-approved" for: 1. any joint account holder 2. a joint account holder who may be identified as a vulnerable customer A DSB interpretation is provided below, but please note that this does not constitute a legal/rules perspective. The recently made v3 rules state that a 'disclosure option management service' must be provided online, and 'may, but need not, also be provided other than online.' See rule 4A.6 in Schedule 4. Our reading is that a joint account holder, including one who may be identified as vulnerable, can use an 'offline' service to amend their disclosure option if the DH chooses to provide one. This must still be done in accordance with the rules, but any alternative channel(s) would be provided at the DH's discretion. The rules do not prescribe how a DH might support vulnerable consumers either - only that DHs will not be held liable for a failure to comply with the Schedule 4 joint account rules if 'the relevant act or omission' was deemed necessary to prevent physical, psychological, or financial harm or abuse. See rule 4A.15.
1080 Problem: As per CDR requirements the state field in the CommonSimpleAddress schema is Mandatory and can be “Free text if the country is not Australia”. Many countries do not use state as a mandatory part of the address e.g. UK uses post code and county. In such cases, the Data Holder does not hold any information in the state field for customers with international addresses and therefore the state field is empty or blank. Question: We would like to understand how to interpret the State field in CommonSimpleAddress schema when it is related to Non Australian Addresses. Can a Data Holder send an empty string (“”) for customers for whom the Data Holder stores international addresses and where the state field is empty or blank? Yes. An empty string would be appropriate if in this specific scenario as it indicates that there is explicitly no value and the field is free text. This would not be appropriate for a domestic address, however as the type of the field is specific in that case.
1081 When sharing Physical address of a customer, is it mandatory to share 1 MAIL or 1 REGISTERED address or can all the addresses be OTHER or PHYSICAL only? The wording in CDR guideline says: "Must contain at least one address. One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail" This can be interpreted as only 1 can be REGISTERED but does not say at least 1 has to be REGISTERED. So, at least one Physical address is mandatory but Purpose can be any of the valid values. Is that correct interpretation? Yes, the standards require only one address to be marked as REGISTERED but do not require that an address must exist that is marked as REGISTERED.
1082 In Get CustomerDetail API response, there is an array "physicalAddresses" that expects one or more customer addresses in the "CommonPhysicalAddressWithPurpose" schema. The array description is "Must contain at least one address. One and only one address may have the purpose of REGISTERED. Zero or one, and no more than one, record may have the purpose of MAIL. If zero then the REGISTERED address is to be used for mail". There is a data element called "purpose" in the response and its description is "Enumeration of values indicating the purpose of the physical address". I have below questions: - If a data holder has only one address in their banking system, can data holder respond the purpose ENUM value as "PHYSICAL"? - If a data holder has multiple addresses in their banking system, can data holder respond the purpose ENUM value as "PHYSICAL" for all the addresses? - Is it must to have at least one address with REGISTERED ENUM value no matter how many customer addresses are available in the banking system? In response to your questions: Q: If a data holder has only one address in their banking system, can data holder respond the purpose ENUM value as "PHYSICAL"? A: Yes. The requirement is not that one of the addresses must be REGISTERED. The requirement is that only one of them needs to be REGISTERED Q: If a data holder has multiple addresses in their banking system, can data holder respond the purpose ENUM value as "PHYSICAL" for all the addresses? A: Yes, although the purposed of REGISTERED is to indicate which one that you, the bank, use to send communications to the customer. I assume you must use one of them for this purpose. Q: Is it must to have at least one address with REGISTERED ENUM value no matter how many customer addresses are available in the banking system? A: No that is not a requirement. As stated the REGISTERED enum is to indicate the preferred address to use for comms (hence the limitation on one). It is best practice to identify one address as the preferred address.
1096 Authorization scope “bank:payees:read” require to share payee information from Data Holder repository. As per CDR documentation, payeeID will be shared (through “Get Scheduled Payments for Account”) with recipient only if scope “bank:payees:read” is consented. Please let us know what information will shared with recipient (instead of payeeId) if customer is not consented with “bank:payees:read” scope. Do Data Holder needs to share payee information (apart from payeeId) under paymentSet/domestic or paymentSet/biller or paymentSet/international based upon type of payee? if the customer has not consented to share their payee data, the payment set would use one of the accountId, domestic account, biller or international payee representations.

Useful Links

View a number of informative and useful links in the Consumer Data Standards Implementation Guide on Information Links.