ACCC & DSB | CDR Implementation Call Agenda & Meeting Notes | 6th of July 2023

CDR Implementation Call Banner

Agenda & Meeting Notes

When: Weekly every Thursday at 3pm-4:30pm AEST
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

Agenda

Introductions
Updates
CDR Stream updates
Presentation
Q&A
Any other business

Introductions

5 min will be allowed for participants to join the call.

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.

House Keeping

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.

Community Guidelines

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.

Updates

Type	Topic	Update
Standards	Version 1.24.0 published 7th of May 2023	Version 1.24.0 Change Log
Standards	Version 1.25.0	Brian will provide an update on when it will be Published
Maintenance	Iteration 16 will commence on the 12th of July 2023	Invitations have been sent out
TSY Newsletter	To subscribe to TSY Newsletter	Link here
DSB Newsletter	To subscribe to DSB Newsletter	Link here
TSY Newsletter	27th of June 2023	View in browser here
DSB Newsletter	30th of June 2023	View in browser here
Consultation	Decision Proposal 229 - CDR Participant Representation	Placeholder: no close date Link to consultation
Consultation	Noting Paper 276 - Proposed v5 Rules & Standards Impacts	No Close Date Link to consultation
Consultation	Noting Paper 279 - Accessibility Improvement Plan	No Close Date Link to consultation
Consultation	Noting Paper 280: The CX of Authentication Uplift	No Close Date Link to consultation
Consultation	Decision Proposal 303 - Maintenance Iteration 15	Link to consultation
Consultation	Decision Proposal 306 - Updates to Banking Product and Account Detail	Feedback closes: 28th of July 2023 Link to consultation
Consultation	Noting Paper 307 - LCCD Consultation Approach	No Close Date Link to consultation Video
Consultation	Noting Paper 308 - Categories of Standards	No Close Date Link to consultation
Decision Made	Decision Proposal 288 Non-Functional Requirements Revision has had the decision made by the Data Standards Chair	Link to the Decision Changes will be incorporated into v1.25.0
Obligation Date: Authorisation Code Flow (ACF)	10th of July 2023 FAPI 1.0 adoption is introduced across four phases. Phase 4: Retire Hybrid Flow: Data Holders MAY retire Hybrid Flow	We are actively encouraging ADRs to test their solution for ACF during the transition window and update their client registration to only use ACF before the July 10th obligation date that permits holders to retire Hybrid Flow. The transition window provides a safer path for ADRs to update their client software in a rolling fashion across all data holders whilst ensuring they have a fall-back mechanism if any given data holder has not correctly implemented ACF. The ACCC is reaching out to participants to gather information regarding the transition from Hybrid to ACF Authorization flow. If any data recipients have feedback they wish to provide regarding their overall experience of ACF, please get in contact with the ACCC at [email protected]. We also encourage recipients to continue raising individual issues with the relevant data holders for resolution.
Engineering	Latest Engineering release(s):	JS Holder SDK: This NPM package (cds-au/holder-sdk) can be included as a NodeJS middleware to support common CDS structures. CDR Participants can use this software development kit (SDK) to implement CDS compliant APIs/endpoints. The latest released version of the Github Repository and the NPM package have been updated to align to the latest CDS version (1.24.0). Link to the latest Github Repository: https://github.com/ConsumerDataStandardsAustralia/js-holder-sdk Link to the latest NPM package: https://www.npmjs.com/package/@cds-au/holder-sdk Test Data Cli: This tool can generate synthetic test data that Mock Data holders can use to serve their resource endpoints to help with CDR implementation. The latest released version of the Github Repository and the NPM package have been updated to align to the latest CDS version (1.24.0). Link to the latest Github Repository https://github.com/ConsumerDataStandardsAustralia/testdata-cli Link to the latest NPM package: https://www.npmjs.com/package/@cds-au/testdata

CDR Stream Updates

Provides a weekly update on the activities of each CDR stream and their work.

Organisation	Stream	Member
ACCC	CTS & Register	Eva
DSB	Consumer Experience	Holly
DSB	Technical Standards - Energy	Hemang
DSB	Technical Standards - Information Security & Banking	Mark
DSB	Technical Standards - Maintenance Iteration 15	Brian
DSB	Technical Standards - Register	James

Presentation

None planned for this week.

Q&A

Questions on Notice

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.

Answer provided

Ticket #	Question	Answer
1873	PART 1 There appears to be some confusion around how the lendingRate and lendingRates objects relate to one another. https://cdr-support.zendesk.com/hc/en-us/articles/4917442200847-Value-for-lendingRates-in-GetAccountDetail-response The above zendesk article suggests that when a loan only has a single current effective rate, then it is acceptable for the DH to return only values for the the lendingRate field and to not return values for the lendingRates field. There is more information contained in the lendingRates object than just the lending rate - such as the loanPurpose. As this additional information is still required consumer banking data under Schedule 3 Rule 3.2(1), Data Holders should still be required to return values for the lendingRates field where they hold the required consumer information, regardless of whether a loan only has a single current effective rate. Can you please: a) confirm that Data Holders are still required to return values for all lendingRates fields when they hold this information; and b) update the afore mentioned zendesk article to clarify this requirement. PART 2 The specific issue we have been facing here is the fact that if "lendingRates" is not exposed then we are unable to receive "loanPurpose" which is required CDR data necessary for our use case. We understand that work will be required from all parties to implement a solution, but at this stage our main priority is to get access to the relevant information as quickly as possible. With that in mind, we were hoping to suggest a potential two part solution to the issue: 1. Encourage all Data Holders who hold "loanPurpose" information to make this information available through the "lendingRates" field for now, even if there is only a single applicable rate. We understand that many Data Holders likely do have this information more readily available and so, as "loanPurpose" is required CDR data, it should be exposed wherever possible. We think this is appropriate and, from our perspective, it would be better to have duplicative information included than to have key fields missing. We think the worst case scenario would be for Data Holders to stop making "loanPurpose" available until a full solution is put in place (including those currently disclosing "loanPurpose" through "lendingRates"). 2. Look at a longer term solution where the standards are amended to move "loanPurpose" and any other relevant information (for instance, "lendingRateType") out of "lendingRates" and potentially into "loan". This will hopefully mean data is provided more consistently in future, but I understand may take some time to be fully implemented. Additionally, though this appears to be the main issue encountered, we are also seeing broader divergences in how industry is providing lending rate information. Some are providing just "lendingRate", some are providing just "lendingRates" and some are providing both (which we understand to currently be the only way to comply with both the Rules and Standards). When issuing guidance on the specific issue raised, it may also be helpful to provide broader clarity on how DHs should be complying more generally.	PART 1 As the guidance states, if an account only has a single effective rate that is applicable to the account, then it may be acceptable for the Data Holder to only provide that value. For an account with only a single rate component (just a simple base rate, for example), this prevents some unnecessary duplication of the rate, which may have just been a single object in the array with the same rate repeated. Any other relevant details about the loan may be found in the "loan" object of the schema. On the other hand, if an account has multiple rate components making up a 'lendingRate', then all components should be included in the lendingRates array. That may be a base (variable or fixed, for example), plus a discount or penalty, as applicable. The sum of all the array items should match total in the single lendingRate field. Even in this case though, you may not find details such as loan purpose or repayment type for an account in operation, as those details may only be relevant at the time of opening an account. You will note that repaymentType is included in the 'loan' object as I noted above. PART 2 Decision Proposal 306 includes changes designed to help improve the supply and interpretation of rate details. If you have any further questions about the proposal, please provide feedback the GitHub issue.
1807	Should a balance record for a credit card account retrieved via the API have the creditLimit field populated? We have seen banks using the currentBalance as outstanding Pending transactions and Available balance as amount left to spend (up to creditcard limit). But this doesnt give an indication on what is the actual credit card balance. ie if I have $95.00 left to spend, there is a difference in what my credit card balance is if my creditLimit is 100 over if it is 10000.	While the creditLimit property is optional, where it is applicable to an account, it should be expected to be populated by the Data Holder. (See Mandatory/Optional Fields under Payload Conventions) As the standard states though, if that property is absent, you may assume the limit is zero, and that may be the intention of the Data Holder. That may be the case if the account was actually a debit card for example, or may have been interpreted as the card not having a predefined limit (though this may be in conflict with having an availableBalance greater than zero for a credit card). Ideally, a Data Holder may provide values for a card with - 10000 limit (creditLimit) 9905 spent (negative currentBalance if money owing) 95 left to spend in this form - currentBalance -9905 availableBalance 95
creditLimit 10000