ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes (4th of February 2021) - ConsumerDataStandardsAustralia/standards GitHub Wiki

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

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
News Introduction and update from Treasury Update from Kate O'Rourke, First Assistance Secretary
Standards Version 1.6.0 Published Link to change log here
Standards Version 1.7.0 Proposed Link to Project Board with proposed changes here
Maintenance 6th Maintenance Iteration planned for 2021 Read about the Maintenance Iteration - If you would like to join these please reach out to [email protected]
DSB Newsletter To subscribe to DSB Newsletter Link here
ACCC Newsletter To subscribe to ACCC Newsletter Link here
ACCC Newsletter 29th of January 2021 Edition View in browser here
DSB Newsletter 29th of January 2021 Edition View in browser here
Consultations Decision Proposal 149 - Energy Draft Feedback Cycle 1 Feedback is now open on any issue related to draft. This thread will remain open until February 12th 2021. At that time proposed changes will be incorporated and a second consultation cycle will commence. Link to consultation
Consultations Decision Proposal 153 - Technical Standards Changes to Accommodate V2 Rules This decision proposal contains a review of the amendments to the CDR rules published on the 23rd of December 2020 to identify changes to the technical CDR standards. This includes the API standards, high level standards and the information security profile. This decision proposal does not cover consumer experience standards or guidelines which will be addressed separately. This thread will remain open until February 19th 2021. Link to consultation
Consultations Decision Proposal 154 - Enhanced Error Handling: Error Code Payload Structure and Transition Arrangements This decision proposal is seeking to address the list of transition arrangements and payload changes to support standardised error codes across the CDR ecosystem. Feedback is planned to be closed on 19th February 2021. Link to consultation
Consultations Decision Proposal 155 - Enhanced Error Handling: Error Code Catalogue This decision proposal is seeking to address the list of standardised error codes and HTTP status codes for error handling across the CDR ecosystem. Feedback is planned to be closed on 19th February 2021. Link to consultation
Consultations Decision Proposal 156 - Enhanced Error Handling: Custom Error Code Discovery Service This decision proposal is seeking to address how participants — particularly ADRs — may discover custom error codes not covered by the standardised error code catalogue are used by servers where commercial / voluntary extensions to the core CDR APIs are offered. Feedback is planned to be closed on 19th February 2021. Link to consultation
Consultations Noting Paper 157 - CX Standards Arising from v2 Rules. This noting paper outlines the anticipated Consumer Experience Data Standards changes arising from the v2 rules being made on 23rd December 2020. Feedback is now open on this noting paper. Feedback is planned to be closed on Friday 12th February, 2021. Link to consultation

CDR Stream Updates

Provides a weekly update on the activities of each of the CDR streams and their workplaces

Organisation Stream Member
ACCC Rules Andrew Breeze
ACCC CDR Register (Technical) Ivan Hosgood
DSB CX Standards Michael Palmyre
DSB Technical Standards - Banking Mark Verstege
DSB Technical Standards - Energy & Engineering James Bligh

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:

Answer provided

Ticket # Question Answer
406 our company is ISO 27001 certified and we also have SOC2 certification. we are in process of devising next course of action to get CDR accreditation. with our existing compliance capability, we are not sure how to approach it. what additional requirements we need to need to fulfil if we have SOC2 and ISO27001 compliance. The ACCC’s Supplementary Accreditation Guidelines: Information Security provide information and guidance to accreditation applicants and accredited persons to assist them in meeting the information security obligation, and to demonstrate that they satisfy the information security obligation for the purposes of accreditation. Of importance will be to what extent these certifications cover your CDR data environment. In addition to the information security obligations in order to be accredited you must also satisfy all the accreditation criteria. Further guidance on the accreditation criteria, the process, and information required, is set out in the ACCC’s Accreditation Guidelines.
423 The signing/encryption keys going in to JWKS, should these be PKIX certificates(issued by a CA) or can we just use a public/private key pair here? Reason for asking this is the rfc https://tools.ietf.org/html/rfc7517, mentions below for x5c value in JWK. There is no need to use the certificates provided by the CA for signing or encryption. The certificates and the JWKS are entirely independent. The algorithm used for signing and encryption is communicated between the ADR and the DH using the OpenID Discovery protocol, for DH capability, and via the information obtained via dynamic client registration, for ADR capability. CDR Support Portal Article
445 Is there going to be any consumer experience guidelines released for the Joint Account Management Service?? There are a lot for Consent flow and consumer dashboard but so far nothing for JAMs.. We are currently developing CX Guidelines for joint accounts, including the JAMS, based on the v2 rules made on 23 December. A workshop on joint accounts is being planned for Q1 in which we'll present and discuss the CX joint account artefacts. We will finalise and release the CX Guidelines shortly after. We've also been contributing to written joint account guidance that ACCC is developing, which they intend to publish soon. Hope that helps but let me know if there's any particular issues that you'd like to see guidance on and we can look to incorporate them into the CX Guidelines. CDR Support Portal Article
448 our members can choose nicknames for their accounts via IB so that they can easily recognise which account is for what...just wondering if on the DH accounts available / unavailable consent screen, can we add the nickname that the member has chosen for their account to this screen? I.e. we would list the nickname with the account type underneath - see example below: Holiday savings (nickname) Savings Account (Account type) BSB ACC Yes, this is absolutely allowed, and we would encourage this approach to align with how consumers identify their accounts outside of CDR. The nickname is also returned to the ADR via the Get Accounts API response as the "nickname" for the account (defined as "A customer supplied nick name for the account), so referring to these accounts using their nicknames in the account selection step will help establish consistency here too. CDR Support Portal Article
457 The new rules for DH dashboard state that it must: "contains any information on the Register of Accredited Persons that is specified as information for the purposes of this rule; and" Where can we find this information? CDR Portal does not have any explicit reference to the rule At this stage the reference to 'information on the Register of Accredited Persons' refers to existing fields - such as the ADR's brand name or software product name - or new fields if they are developed in the future. This issue is still being defined and will be consulted on further. Noting Paper 157 touches on what is currently anticipated. CDR Support Portal Article
458 We have chosen to use solutions from different providers for Product Reference Data and Consumer Data. The Consumer Data Standards require Data Holders to host two endpoints, Get Status and Get Outage. Are you able to provide some guidance on which vendor should be responsible for the endpoints - assuming only one can do this? Would we need to manage both vendors to adhere to the availability requirements? The outages and status APIs are intended to represent your CDR implementation as a whole. If there is an outage in either PRD or Authenticated APIs then the outage and status API responses should reflect this. As long as you meet this obligation you comply with the standards. It is up to each Data Holder to choose how to do this. In your case you could ask vendor A, vendor B, a combination of A and B or even a third vendor C to publish these APIs. CDR Support Portal Article
461 I believe we may have some customers that have a fax number recorded on our systems. Should we - - share it against the OTHER enumeration in the CommonPhoneNunber schema - don't share it - raise a change request to include a new enumeration in CommonPhoneNunber schema We also have some numbers stored as type 'Direct' - should they be shared as OTHER? https://consumerdatastandardsaustralia.github.io/standards/#tocScommonphonenumber In both cases the intention of the spec was to use the OTHER enumeration value. I can understand the case that fax should be added as it could be unproductive for an ADR to attempt to ring a fax line. If you think this would be of value then I would recommend raising a change request. CDR Support Portal Article
470 I have had a question/concern from the team about whether what may be considered OTHER addresses should be shared in the Customer Detail payloads. In many cases these addresses may contain the name ('mailingName') and address of another person related to the customer/entity that is providing sharing authorisation, only for the purposes of receiving statements or a cheque book delivery, or cards etc. The addresses may be accountants or other related parties. Should all these 'OTHER' addresses on file for a customer be shared in the Get Customer Detail endpoint? I don't think the data cluster language refers to the potential for information about other people/addresses being shared. The simple answer is yes they should be included if they are addresses added by the customer for the use by the Bank for that customer. Addresses from other customer records, even if they are related, shouldn't be added but that is a different scenario. CDR Support Portal Article
474 For the API “Get Scheduled Payments”, under “BankingScheduledPayment”, there is a filed called “status” with description “Indicates whether the schedule is currently active. The value SKIP is equivalent to ACTIVE except that the customer has requested the next normal occurrence to be skipped.” The field however has an enumerated value “INACTIVE” whose purpose is not clear in the field description. Would you kindly let us know what exactly are we referring to with the INACTIVE status for Scheduled Payments? INACTIVE was included for situations where a payment schedule exists (and therefore should be ashared) but it has been paused or suspended either temporarily or indefinitely for some reason. CDR Support Portal Article
484 I would like clarification as to whether the following Optional/Conditional fields must be included by Data Holders if applicable: The “specificAccountUType” field in the BankingAccountDetail object is specified as “optional” in the schema, however, is it mandatory for us to include it if the account is a Term Deposit, Credit Card or Loan? Similarly, the following are “conditional” fields in the BankingAccountDetail object, but are they essentially mandatory if the account is a Term Deposit, Credit Card or Loan? (conditional on “specificAccountUType”) • termDeposit • creditCard • loan The “features” field in the BankingAccountDetail object is specified as “optional” in the schema, however, is it essentially mandatory for us to include if the account has features if the equivalent product has those product features in the Product Reference data? The “depositRates” and “lendingRates” fields in the BankingAccountDetail object are specified as “optional” in the schema, however, is it essentially mandatory for us to include them if the equivalent product has those rates in the Product Reference data? Question: The “specificAccountUType” field in the BankingAccountDetail object is specified as “optional” in the schema, however, is it mandatory for us to include it if the account is a Term Deposit, Credit Card or Loan? Answer: The specificAccountUType field is a discriminator for the schema to identify which one of a series of optional structures will be present. As we have only included the termDeposit, creditCard and loan structures for additional inclusion that is all that is included in the specificAccountUType enum list. Hence why the UType is optional. If the type of product being described is one of the three supported and can be expressed in a compliant manner, then the additional data is required. Having this optional means we don't have a bunch of exceptions to handle things like obscure lending products that don't have interest rates for instance. Question: Similarly, the following are “conditional” fields in the BankingAccountDetail object, but are they essentially mandatory if the account is a Term Deposit, Credit Card or Loan? (conditional on “specificAccountUType”) Answer: That is correct - see answer above. Question: The “features” field in the BankingAccountDetail object is specified as “optional” in the schema, however, is it essentially mandatory for us to include if the account has features if the equivalent product has those product features in the Product Reference data? Answer: It is optional from the perspective that not all accounts or products may have features. However, if the account has a set of relevant features as described in the associated PRD product record or negotiated by the customer these must be shown. It is not optional for the DH to exclude showing features if they apply. Question: The “depositRates” and “lendingRates” fields in the BankingAccountDetail object are specified as “optional” in the schema, however, is it essentially mandatory for us to include them if the equivalent product has those rates in the Product Reference data? Answer: That is correct. These should be the rates applicable to the account which might include negotiated rates (not the publicly offered rates). They are optional because it is dependent on the type of account whether that part of the schema is applicable. CDR Support Portal Article
491 We seek feedback on best approach in using the Lending Rate Type = Introductory. If you take the example of a credit card (where use of introductory rate/s are common) we typically have a cash-Advance and a purchase rate. Similarly, we would have both an introductory cash advance rate and an introductory purchase rate (when applicable). We would expect to use the rate type Introductory for each of these but include in Additional Info "Cash Advance" or "Purchase" as required. Under the current schema the approach you have described would be appropriate. If you believe the schema should be extended to accommodate more specificity as to the type of introductory rate (or moving the introduction flag from the enumeration to a separate indicator) then we would welcome a change request on standards-maintenance. CDR Support Portal Article
502 just wanted to follow up with regards to a comment I posted on this thread, as it is sitting in "pending approval" - https://cdr-support.zendesk.com/hc/en-us/articles/900002670766-Grandfathered-Product-Reference-Data-PRD-for-Public-vs-Customer-endpoints The question I have is: With regards to: (response in the article) You must provide data on grandfathered accounts for type 2 (the authenticated, customer specific account APIs). Are features provided in this array meant to be specific to customer circumstance or just mirror equivalent (if any in PRD)? Example would ADDITIONAL_CARDS = 4 in this context mean that 4 additional cards are available for the product or that the customer in context has 4 additional cards? It would be the former. If the customer has taken up 3 cards however the account feature allows the customer to have 4 cards, the feature would 4. The additionalInfo field may be used to describe the current number of cards the consumer has noting that the customer can apply for one more additional card. CDR Support Portal Article

Response pending

Updating the table belwo - 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.

Ticket # Question Answer

Question and answers

# Question Answer/ Action

Useful Links

Organisation Description Link
OAIC Main landing page for the Office of the Australian Information Commissioner and the Consumer Data Right Link