ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 8th of August 2024
When: Weekly every Thursday at 3pm-4:30pm AEDT
Location: Microsoft Teams
Meeting Details: Join on your computer, mobile app or room device Click here to join the meeting
Meeting ID: 446 019 435 001
Passcode: BU6uFg
Download Teams | Join on the web
Join with a video conferencing device
[email protected]
Video Conference ID: 133 133 341 4
Alternate VTC instructions
Or call in (audio only)
+61 2 9161 1229,,715805177# Australia, Sydney
Phone Conference ID: 715 805 177#
Find a local number | Reset PIN
Learn More | Meeting options
- 5 min will be allowed for participants to join the call.
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.
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.
By participating in the Consumer Data Right Implementation Call you agree to the Community Guidelines. These guidelines intend to provide a safe and constructive space for members to discuss implementation topics with other participants and members of the ACCC and Data Standards Body.
⭐ indicates change from last week.
| Type | Updated | Links |
|---|---|---|
| Standards | Version 1.31.0 | Published: 3rd of July 2024 Change log |
| Maintenance | Iteration 20 Commenced 10th of July 2024 |
Sign-up and Register Data Standards Body Events |
| Maintenance | Iteration 20 Schedule: 21/08/2024 Proposal Checkpoint 4/09/2024 Approvals and Documentation |
MI20 Agendas and Minutes |
| DSB Newsletter | To subscribe to DSB Newsletter | Link here |
| DSB Newsletter ⭐ | 2nd of August 2024 | View in browser here |
| Consultation | Decision Proposal 229 - CDR Participant Representation | Placeholder: no close date Link to consultation |
| Consultation | Noting Paper 279 - Accessibility Improvement Plan | No Close Date Link to consultation |
| Consultation | Noting Paper 323 - NFR Workshops | Link to consultation |
| Consultation | Noting Paper 351 - LCCD Risk workshop summary | No feedback sought Link to Noting Paper |
| Engineering | Test Data Cli: The Github Repository has been updated to align to the latest CDS version (1.31.0). | See latest npm package. |
| Guidance | The ACCC has revised the Accreditation guidelines to update references to CDR Rules and Standards, including to reflect version 5 of the CDR Rules. | Accreditation guidelines |
Provides a weekly update on the activities of each CDR stream and their work.
| Organisation | Stream | Member |
|---|---|---|
None this week.
Questions will be received by the community via Microsoft Teams chat before the questions are opened to the floor. Participants can submit questions outside of the CDR Implementation Call to the CDR Support Portal.
In regards to topics for questions, we ask the participants on the call to consider the Community Guidelines when posing questions to the subject matter experts.
| Ticket # | Question | Answer |
|---|---|---|
| 2392 | As a dataholder providing a DCR service we perform some basic SSA validations on the registration payload, one of these is validating that the various URIs provided as part of the DCR request are https - and not http ( client_uri, redirect_uris, logo_uri, jwks_uri, etc) This is in line with our cyber policy as well as the standards 1) All normative examples for DCR have https:// https://consumerdatastandardsaustralia.github.io/standards/#client-registration 2) Transaction Security All HTTP calls MUST be made using HTTPS incorporating TLS >= 1.2. NOTE - On the standards websites - all examples for URIs are https 3) Validations on CDR Sandbox tooling also enforce https a) Would like to seek clarification as to why does the URI String example use http? https://consumerdatastandardsaustralia.github.io/standards/#common-field-types URIString A valid URI "http://www.google.com/" (This is the only spot where http:// has been used as an example) Also - we believe the Register should also enforce the use of https as part of the on-boarding -when the ADR's brand is set up in the register. It seems that there is at least an example of one ADR's brand registered with ACCC using http:// for their various URI endpoints and our Auth Servers SSA validation will reject their request based on the fact that the URI's are http:// Allowing http could pose a risk to our systems We believe that The ADR should update their registration properties to use https:// instead of http rather than requiring dataholders to support http for URI endpoints Any guidance on the way forward and the approach towards the use of http in the URIs will be greatly appreciated |
I've raised a request to change the URIString example in the current Maintenance Iteration. I don't believe there was a particular reason the example used 'http', other than it being a generic URI. My thinking in how some of the DCR fields relate to the overall requirements for transaction security is that the client_uri and logo_uri for example, are not directly involved in data sharing, but as you've stated, the logo_uri could cause a security concern or policy warning if integrated into an https web page in part of the process. The redirect_uri and jwks_uri could be a different type of concern. Can you clarify for which field the ADR provided an http URI, and whether you have asked them to change it to https? (and, if they weren't able to do so, if they had any specific reason?) |
| 2404 | I have a question I’m hoping that you may be able to provide some clarity on regarding the interpretation of the data within the Credit card Schemas (https://consumerdatastandardsaustralia.github.io/standards/#cdr-banking-api_schemas_tocSbankingtermdepositaccount) The question I have is in relation to “minPaymentAmount” and “paymentDueAmount” and if these should be the same value or different? My understanding is they should be different values as if they were the same value, it would prevent the following information to be relayed from the endpoint where the payment due amount and minimum payment amount are different, for example: E.g.: Closing balance to be paid off: $5,000.00 (we expect this value to be reflected in paymentDueAmount) to avoid any interest charges. Minimum payment amount: $50.00 (we expect this value to be reflected in minPaymentAmount) to avoid going into arrears. |
The two fields are to cater for products where the consumer can either pay the full balance in their next due payment (paymentDueAmount; usually to avoid interest on any remaining balance), or pay a minimum agreed amount (minPaymentAmount; usually a percentage of the full amount, as specified in the terms of the product) with the remaining balance plus interest rolled over to the next payment cycle. I would suggest that the minPaymentAmount should always be equal or lower than any full paymentDueAmount. If the account doesn't offer the capability of accepting part payments, the minimum payment due would match the full payment due, as the minimum is the full amount. I think that aligns to the example you provided based on your understanding, unless there's some different variations you're concerned about, or aware of in certain conditions? |
| 2406 | What's the definition of executionDateTime in Transaction? Saw it is defined as: The time the transaction was executed by the originating customer, if available. A PENDING transaction, should it with an executionDateTime? |
Yes, an executionDateTime value could be applicable for PENDING transactions. I believe it would be the time the transaction was actioned by, or on behalf of the consumer. Are you aware of situations where it may not be applicable? |
| 2407 | It was highlighted by DSB in a recent MI call that our response for Get Product Details API in the example below might be incorrect for minimumValue and maximumValue. I just want to confirm that the expectation of maximumValue when the unitOfMeasure = PERCENT should be 0.70 instead of 70.00. The ADR is expected to understand it is 70 PERCENT and not 0.70 PERCENT. "lendingRateType": "DISCOUNT", "rate": "-0.0209", "calculationFrequency": "P1D", "applicationFrequency": "P1M", "interestPaymentDue": "IN_ARREARS", "repaymentType": PRINCIPAL_AND_INTEREST", "loanPurpose": "INVESTMENT", "tiers": [ { "name": "Basic Variable LVR <=70%", "unitOfMeasure": "PERCENT", "minimumValue": 0.00, "maximumValue": 70.00, "rateApplicationMethod": "WHOLE_BALANCE" |
The issue I was referring to was - #614 - Definition of PERCENT in BankingProductRateTierV3. The intent is that rates (percentages) are generally described as a RateString across the Standards for consistency. While it it is not binding, the Candidate Standards demonstrate the proposed change. |
Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.
View a number of informative and useful links in the Consumer Data Standards Guide on Information Links.
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |
 |