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

ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4.30pm AEST
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
Standards Version 1.11.0 Published Link to change log here
Standards Version 1.11.1 Drafted Standard-staging Version 1.11.1 Change log for Version 1.11.1
Maintenance 8th Maintenance Iteration Closed Agenda from the 8th of September 2021 meet
Maintenance Decision Proposal 202 - Banking Maintenance Iteration 8 Link to consultation
Maintenance 9th Maintenance Iteration Kicked-off Agenda from the 8th of September 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 18th of August 2021 View in browser here
DSB Newsletter 3rd of September 2021 View in browser here
Consultation Decision Proposal 190 - Candidate Generic Tariff End Point Link to consultation
Consultation Decision Proposal 193 - Energy Non-functional Requirements Link to consultation
Consultation Decision Proposal 194 - Candidate NMI Standing Data End Points Link to consultation
Consultation Decision Proposal 195 - Candidate Usage End Points Link to consultation
Consultation Decision Proposal 196 - Candidate DER End Points Link to consultation
Consultation Normative Standards Review (2021) Link to consultation
Consultation Decision Proposal 206 - Register Standards Link to consultation
Consultation Decision Proposal 208 - Binding NFRs Link to consultation
Action Implementation Call 2nd September - Clarification of the verbal response to the question relating to CTS test plan version prior to November obligations. As per the Participant Conformance Approach the ACCC will allocate participants the most relevant test plan for their obligation date. In regards to November 2021 obligations the most relevant CTS test plan is v3.3 and participants can request to be allocated v3.3 in the lead up to November obligations. CTS test plan v3.4 is backwards compatible and will be available for those that wish to test to the latest version that includes enhanced error handling. Please do not hesitate to reach out and discuss with your ACCC contact via [email protected] Note - as per the Participant Conformance Approach under certain circumstances, the Registrar may mandate active participants to retest their solution through the CTS. The Registrar will confirm the test plan to be completed.
Update In a recent CDR Implementation Call there was a query about an explanation of what changes had been made to the CDR Privacy Safeguard Guidelines. The Office of the Australian Information Commissioner are pleased to report that the OAIC’s Summary of Version changes document is now available on our website here. This document sets out in detail the changes made to each Chapter for the most recent update to the CDR Privacy Safeguard Guidelines. Link to the Summary Version

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
ACCC Onboarding Jonathon Ingle
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
903 We are having some discussion internally about what should be displayed via an ADR for a term deposit “account Balance”. At the moment the ADRs are displaying “available balance” rather than current balance (where the latter is the principal) This consequently looks really odd because it looks like your TD is $0 when actually that is what is currently “available” to you Can you clarify how Open Banking is meant to work in the spirit of how it works for the customer because seeing $0 on my screen is not helpful I don’t think? what have other TD providers done with this product. RAB are doing what we are doing apparently. ie For CDR-DH: Current Balance is the principal amount of the term deposit. Available Balance is fixed at 0.00. The structure contains available balance and current balance and communicates the difference. The DSB does not take any position on how the ADRs use the data they receive, although we do provide clarification when they ask for it. Depending on the experience an ADR is trying to deliver the use of available balance vs current balance may be appropriate. If you are concerned about a specific ADR's use of balance information I would recommend communicating the concern you have to them directly.
1021 We have products that have multi-tiered rates that depends upon more than just one variable. Like for example for one of the saving products, If the customer maintains $100k balance for 30 days a different rate is offered and a different rate for 60days and so forth. Respectively there are different rates offered for different balances that customer maintains for 30days, 60 days, 120 days..... The two variables that define the rates is based upon the customer's balance and duration the balance is maintained. In such a case how is the BankingProductRateTierV3 fields updated? What will be value for Unit of Measure, Min and Max value and RateApplicationMethod as in this case its a combination of DOLLAR and MONTH? Snapshot attached The schema has been designed to accommodate this level of complexity. Multi-tiered rates are common for Term Deposit and Mortgage accounts. A number of examples exist for how to represent accounts of this type. I would recommend taking a look at how ANZ and Westpac represent their Term Deposit accounts for instance. You can see their data via the DSB hosted comparator tool (https://consumerdatastandardsaustralia.github.io/banking-products-comparator/).
1034 We noticed that a discount type PAYMENTS has following description: Discount for outbound payments from the account under a certain amount of money in a period. As the discount applies to a fee the period is the same as for the fee Our understanding is that the discount is meant to describe a fee which is discounted when a customer spends a certain amount, in which case the documentation should say "over" instead of "under". Can you please clarify? Question: Discount for outbound payments from the account under a certain amount of money in a period. As the discount applies to a fee the period is the same as for the fee Our understanding is that the discount is meant to describe a fee which is discounted when a customer spends a certain amount, in which case the documentation should say "over" instead of "under". Can you please clarify? Answer: The language is intentional. The intent was for accounts where fees are discounted or removed if money is not taken out of the account (ie. for savings accounts).
1038 How do we handle pagination for transaction history in the case of removed transactions? E.g. if there is reversal whereby we remove a transaction in the Digital history. If it occurs on the 1st page of results just as an ADR is requesting the next page, they may miss records depending on how they implement their solution. this is dealt with in the standards. Specifically, under Additional Pagination Rules (https://consumerdatastandardsaustralia.github.io/standards/index.html#pagination): "Holders are not expected to implement pagination with transaction isolation. The underlying data-set may change between two subsequent requests. This may result in situations where the same transaction is returned on more than one page."
1040 The new CTS v3.4 will be released soon with error handling scenarios. Can you help confirm that participants can still use CTS v3.3 after the new version is released to continue testing for November compliance dates. Also would be good to know what these error handling scenarios relates to? In regards to November 2021 obligations the most relevant CTS test plan is v3.3 and participants can request to be allocated v3.3 in the lead up to November obligations. CTS test plan v3.4 is backwards compatible and will be available for those that wish to test to the latest version that includes enhanced error handling.
1043 Below are some questions we have on open on consent amendment: 3rd bullet from this link states that: Data Recipients MAY provide an existing cdr_arrangement_id claim in an authorisation request object to establish a new consent under an existing arrangement. Our assumption is that if cdr_arrangement_id is NOT provided by DR, then it is a new consent, and when cdr_arrangement_id is provided then we have to amend existing consent. But from the statement above, if a DR sends an existing cdr_arrangement_id how do we distinguish between a request for consent amendment Vs new consent. When will the CX guidelines for consent amendment updates on consumer dashboard be published? Technically consent amendment cannot occur under the CDR. If an arrangement ID is provided then the existing consent is revoked and a new consent is established in a single transaction. Both the old consent and the new consent should have the same arrangement ID. This effectively results in consent amendment without having to deal with the complexities of changing a previously authorised consent. The language that is used is deliberately aligned to this approach. On your second point, there is no CX guidance for consent amendment on the ADR or DH dashboard and consent amendment cannot be achieved via either dashboard. The full consent authorisation flow must be undertaken. The only actions that can be taken at a dashboard are the changing of election (at the ADR dashboard) and consent revocation (at both dashboards).
1050 Is there a requirement that Data Holders validate the scopes requested in an authorisation request against the scopes provided by the ADR in the SSA during client onboarding (DCRS)? So for example ADR1 registered scopes1 and 2 with the DH1 during DCRS. Later ADR1 requests scopes1 and 3 be included in an authorisation for customer1. Should the Data Holder reject the authorisation all together, include both scopes in the authorisatio or include only the valid scope (scope1) in the authorisation. Yes, validation should occur. The scopes in the SSA represent a whitelist of scopes that are supported for the given client (in this case the Software Product). OIDC Core requirements outline what scope validation is required during the authorisation request. The CDS refers to the normative references which define these requirements.

Useful Links

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