ACCC & DSB | CDR Implementation Call Agenda & Minutes | 16 April 2026 - ConsumerDataStandardsAustralia/standards GitHub Wiki

imp-call_header

Agenda

Sign up: Sign Up
When: Third Thursday of the month at 3pm-3:45pm (Canberra time)
Location: Microsoft Teams (dial in details are below)

Join on your computer, mobile app or room device
Click here to join the meeting
Meeting ID: 487 742 173 354 95
Passcode: AN6KY2Lp
Dial in by phone
+61 2 9161 1229,,665346196# Australia, Sydney
Find a local number
Phone conference ID: 665 346 196#

Agenda

  1. Introductions
  2. House Keeping
  3. CDR Stream updates
  4. General Updates
  5. Q&A
  6. Non-Bank Lenders Special Segment
  7. Any other business

Introductions

imp-call_intro

  • 5 min will be allowed for participants to join the call.
  • This call is jointly facilitated by the ACCC and the DSB, and we welcome observers from APRA, OAIC and the Treasury.

Acknowledgement of Country

We acknowledge the Traditional Custodians of the various lands on which we meet today and pay our respects to their Elders past and present.

House Keeping

imp-call_house-keeping

Recording

The Consumer Data Right Implementation Calls are recorded for note taking purposes only. Recordings and transcripts are kept securely. No identifying material is provided without the participant's consent. Participants may email [email protected] with any questions or a request to have 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.

CDR Stream Updates

imp-call_stream-updates
Provides an update on the activities of CDR streams.

Organisation Topic Member Minutes
ACCC & DSB A special Non-Bank Lending segment will be held at the end of the call to hold discussions, walkthroughs and presentations ahead of go live

General Updates

imp-call_updates

⭐ indicates change from the last call.

Type Updated Links
Standards CDR Data Standards v1.36.0 was published 4 December 2025. The release contains changes from Decision 376 (White label brand arrangements).

There are 2 Future Dated Obligations approaching on 13 July 2026:
DSB Newsletter ⭐ The DSB Newsletter publishes monthly on the Friday following the implementation call and will include a summary of discussions from the call.
Implementation Call ⭐ The Implementation Call meeting invites will be extended by another 3 months through to July. If you have previously signed up you will receive a new meeting invite this week Sign Up
Summit ⭐ The inaugural Fintech Data Horizons Summit is being held on May 8 at the Sofitel Sydney Darling Harbour. This summit is a one-day event, evolving from the CDR Summit and Fintech for Net Zero. Tickets

Q&A

imp-call_q+a

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.

To view questions and answers from previous CDR Implementation Calls, click here.

Questions on Notice from the March Implementation Call

Sector Question Answer
Banking Is there any update on the Treasury proposal to introduce a de minimis threshold in the banking sector? The Treasury provided the below update post-call:
The introduction of a possible de minimis threshold for the banking sector is still under consideration by the Government. As noted previously, this work is only examining arrangements for the banking sector. Changes to other sectors are not being looked at.
Banking (DH) Traffic Thresholds
Are the traffic thresholds for Customer Present and AuthZ traffic to be considered discretely from the thresholds for unattended traffic? Specifically, with regard to the 50TPS per software product NFR, during low traffic periods should DH's support a minimum of 100TPS per software product in aggregate?
Are the traffic thresholds for Customer Present and AuthZ traffic to be considered discretely from the thresholds for unattended traffic?
Yes, because they are two different types of traffic to evaluate:
  • For customer-present resource requests (with the x-fapi-customer-ip-address header present and populated) and authorisation requests (PAR, authorise, token, revocation, etc.) - you must support the specified levels before rejecting on this basis alone.
  • For unattended requests - resource requests without the IP header (customer is not present) - you must support the specified levels before rejecting on this basis alone.
Specifically, with regard to the 50TPS per software product NFR, during low traffic periods should DH's support a minimum of 100TPS per software product in aggregate?
  • The specification is 50 TPS of each type, not just 100 TPS total of any type. If you suspect that ADRs are not specifying the x-fapi-customer-ip-address header in the context in which it was intended, you could discuss with the ADR or the ACCC.
  • According to the current definition of "low traffic period" (midnight to 6AM) it may be unusual for a very high volume of customer present requests.
Aside from these 'per Software Product' levels, the overall threshold (that applies across ADRs) then applies across both those request types - "For secure traffic (both Customer Present and Unattended) the following traffic thresholds will apply".
Banking (DH) Lending Adjustment Rate - Penalty
Based on a review of various financial institutions' current implementations, the Lending Adjustment Rate - Penalty field within the Consumer Data Standards (Banking) appears to be largely underutilized or inconsistently applied.

1. Intent and Calculation
The Standards define this as a "specific penalty rate that may be applied" where the Effective Rate is calculated as (Base + Penalty).

During the CDR call on 19/03/2026, the example provided suggested that if a "Penalty Rate" of 0.5% is applied, the expected value is the sum of the base and the penalty. This approach creates a high maintenance burden, as the field must be updated every time a base interest rate changes.

Was it the intention of the Standards for this field to be a dynamic "effective rate" (Base + Penalty), or could it be interpreted as a static "margin" (e.g., just the 0.5%) that is added to the base? A static margin would be far more stable and easier for Data Holders to maintain.

2. Terminology Concerns
The term "Penalty" carries significant weight and often does not align with the terminology used in customer-facing contracts or internal banking systems in Australia (where "Default Rate" or "Arrears Loading" is more common).

Would the DSB consider reviewing the naming convention for this field to better reflect industry-standard terminology and reduce potential consumer confusion?		 1. The value of an adjustment rate is the adjustment amount only, not a sum. For the example on the call, I believe the suggestion was that the rate the customer would be paying would be the base plus the adjustment, it wasn't to imply that the adjustment in the API response is expected to specify the total effective rate.

The standards state "A product may have zero, one, or multiple adjustment rates that are taken to apply to a Base rate." The formula described in the standards (Base + Penalty) is how data recipients should expect to use the values to determine an effective rate.

2. The label PENALTY is essentially a static data attribute that has been part of the standards since 2018 and is unlikely to be changed at this point, although you may raise a change request if you feel that a change is justified. That specific text may not necessarily be made visible to consumers as other associated fields including additionalInfo and additionalValue would likely provide better context.

Additional Q&A

Ticket # Sector Question Answer
2679 Non-Bank Lenders ACCC Bi-Annual Reporting
When will we need to submit our first bi-annual reporting to the ACCC per rule 9.4?		 A non-bank lender data holder that commences PRD sharing between 1 July – 31 December 2026 is required to submit their first biannual participant report by 30 January 2027, for the 1 July to 31 December 2026 reporting period.

A non-bank lender data holder that commences PRD sharing on or before 30 June 2026 is required to submit their first biannual participant report by 30 July 2026, for the 1 January to 30 June 2026 reporting period.

Rule 9.4(5) of the CDR Rules provides that the bi-annual reporting periods are:
  • 1 January to 30 June of each year; and
  • 1 July to 31 December of each year.
Reports must be submitted every 6 months, by 30 January and 30 July each year. For more information see the rule 9.4 reporting page on the CDR website.

The CDR website includes sample reporting forms for Rule 9.4 reporting.
Verbal Question 1 Non-Bank Lenders What resources can I lean into to make sure that I'm completely up to date and can refer to to make sure that I am meeting obligations?
Verbal Question 2 Non-Bank Lenders How can we discern whether or not a product is covered and whether we're going to need to provide specifications for the product. An example is a wholesale white labelling agreement with loan managers and is not available directly to the consumer or to the public. For some general guidance on assessing whether a product is in scope or not - refer to guidance on Assessing whether a banking or non-bank lending product is in scope for CDR otherwise raise a support portal query.

Non-Bank Lenders Special Segment

NBL

Topic Minutes
1. ACCC has published guidance on Sharing product data in the non-bank lending sector
  • DSB Run through of technical PRD Guidance examples
 This has been put together in response to feedback that some NBL sector products have highly variable pricing, with specific rates offered to a consumer depending on a significant number of factors. Interest rates can be shared using the BankingProductLendingRateV3 field to support products with a single rate, from or maximum rate or rate range. There is information on how to handle highly bespoke products and on products that are not publicly advertised and the obligations around disclosure of it.
2. ACCC Compliance comments on:
  • ACCC approach to CDR Compliance
  • CDR Public rectification schedule explained
 Participant Engagement update
  • The participant engagement team have commenced engagement meetings with the initial and larger providers in the NBL sector. These meetings are to guide participants and support you on the journey through the onboarding process. If you are an initial or large provider and have not yet engaged with the participant engagement team, please email [email protected].
ACCC approach to CDR Compliance
  • Monitoring compliance and enforcement of CDR regulatory obligations is jointly conducted by the ACCC and the OAIC. The approach to compliance and enforcement activities is outlined in the ACCC/OAIC Compliance and Enforcement Policy for the CDR.
  • The compliance and Enforcement Policy highlights that we seek to be proportionate in our response to potential non-compliance. To inform our response, when assessing potential non-compliance and deciding whether to take regulatory action, we take into account the factors set out in the CDR Compliance and Enforcement Policy. For example, we have regard to:
    • the impact of the non-compliance, including harm or risk of harm to consumers
    • action taken to minimise the impact of the non-compliance, including the extent and duration of the non-compliance; and
    • whether there has been transparent and timely communication to consumers, CDR participants, and the ACCC, about the non-compliance - including whether the non-compiance was selt-reported.
CDR Public rectification schedule explained
  • The ACCC's CDR public rectification schedules provide information about reported implementation gaps, increasing transparency for participants on the types of implementation gaps and when they will be resolved.
  • We assess information reported on the rectification schedules for severity. In some instances, we may put in place additional measures such as regular reporting on activities towards rectification or take steps to investigate the self-reported issue further.
  • Presently, there are three public rectification schedules with distinct purposes, two of which may be of relevance to non-bank lender data holders:
  • Reporting an implementation gap, and inclusion on the public rectification schedules, does not preclude the ACCC from pursuing further compliance or enforcement action either now or in the future.
3. Video walkthrough of Registration + PRD process has been published and is available from the CDR website: Additional Resources:

Any Other Business

imp-call_any-other-business

Attendees are invited to raise topics related to the Consumer Data Right that would benefit from the DSB and ACCCs' consideration.

Minute
The ACCC CDR Compliance team is running a survey to better understand both:
  • the current state of data quality in the CDR
  • the main concerns of CDR participants and other users of CDR data.
We encourage interested parties to take the survey, which is open until 28 April 2026.
Take the CDR data quality survey

Survey participants can also provide their contact details to the ACCC if they want to share further information about their experiences with data quality.

The Next CDR Implementation Call

The Next CDR Implementation Call

21 May 2026

Thursday, 3:00pm (Canberra Time)

Minutes from the previous Implementation Call (19 March 2026): https://github.com/ConsumerDataStandardsAustralia/standards/wiki/ACCC-&-DSB-%7C-CDR-Implementation-Call-Agenda-&-Minutes-%7C-19-March-2026

Useful Links

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

Data Standards Body Consumer Data Right Digital ID Contact & Media
Chair Standards Accreditation Standards Website
News Maintenance Iteration AGDIS Standards Email
Advisory Committee CX Guidelines Calendar
Support Portal LinkedIn
YouTube
GitHub
Newsletter
⚠️ **GitHub.com Fallback** ⚠️