Welcome to the Consumer Data Right Support Portal

Check out our guides, browse through our FAQs, and post your own questions for Support.

New to the Consumer Data Right? Learn more

2026 Implementation Call Q&A Follow

  • Created:
  • Last edited:
  • Updated

Important Notice

The contents in this page lists the questions and answers that are raised in the CDR Implementation Call. This includes questions that have been responded to on the CDR Support Portal in the month prior to the call, with any identifying or sensitive information removed. The responses provided are general in nature and current as at the date of publication. Responses do not constitute legal or other professional advice and should not be relied on as a statement of the law in any jurisdiction.

The CDR Rules and Standards are revised from time to time. Parties should ensure that they consult the current version of the CDR Rules and Standards to understand their obligations, and consider the need for independent professional advice to assess whether a particular implementation is compliant with the CDR legislative framework.

CDR Implementation Call

The fortnightly CDR implementation call provides an accessible forum for participants to raise questions, and provides updates on the CDR and standards changes. These meetings offer an opportunity to better understand how to interpret and implement the rules, CX and standards. The calls are co-facilitated between the ACCC and the Data Standards Body to ensure that all participants have access to support across all aspects of the CDR.

You can sign up to the fortnightly calls using the DSB Calendar. You can find further information about the CDR Implementation Calls here. To ask a question, use the online form on this site or join the Implementation Call.

CDR Implementation Call Q&A

Date Ticket Sector Question Answer
21/05/2026 2697 Non-Bank Lenders CDR Lending Rate Reporting - Ranges

For specific products that have multiple lending rates that vary depending on defined LVR ranges, for CDR reporting purposes, could we report with Min and Max values instead of having to detail every single rate?		 The CDR Rules require data holders to provide a product data request service and disclose required product data in response to valid requests. These disclosures must include all requested required product data that they hold in digital form including information that is contained on the data holder’s website or in a disclosure document that relates to the product. The guidance on Sharing product data in the non-bank lending sector has been updated to provide further guidance on when product data must be shared including the interpretation of “data holder’s website”.

The CDR Rules also require that all data be disclosed in a manner that conforms to the Consumer Data Standards (Standards). This means that, where a structured field is available, that structured field must be used to disclose required product data.

Available data about lending rates and criteria applicable to the rates is considered required product data. Therefore, if available, the data such as LVRs or LVR ranges (60% or less, 60.01% - 70%, etc.) and loan amount (‘Home loans ≤ $3.5m’) must be disclosed using available structured fields outlined in the Standards.

The schema has been designed to accommodate this level of complexity for product data disclosures. Particularly, BankingProductLendingRateV3 and BankProductRateTierV4 support the disclosure of the rates and applicable criteria described in your specific example. You can also see Guidance on lendingRates fields published by the DSB for more information, including an example at the end of the page describing a home loan product that is offered with three different rate options, and further information on examples here.

For more information about required product data, see section 5.3 of our Compliance guide for data holders in the banking and non-bank lenders sectors. Please also see Clarification of specific Data Quality obligations for guidance on assessing whether data must be shared under the CDR Rules and the meaning of Mandatory, Optional and Conditional in the Standards.
21/05/2026 2692 Non-Bank Lenders

isTailored and risk-based pricing

What lending rate information should be included in PRD for products that use risk-based pricing. For example, is it acceptable to omit lending rate information where rates are not publicly disclosed on a provider’s website, or should certain baseline information, such as minimum, maximum and representative (mid-point) rates, always be included? Specific questions:

  1. Are there any circumstances in which it is appropriate to set isTailored to true for a risk-based priced product? For example, where interest rates are not publicly published.
  2. How should this be treated where interest rates are publicly published, including scenarios such as “from 10.99% p.a.” or “between 10.99% p.a. and 20.99% p.a.”?
  3. How should this be treated where interest rates are only available through an online quote tool that requires the consumer to provide information, such as their credit score, in order to see a personalised rate?
  4. How does this compare with home loan products, where an advertised rate (effectively the maximum rate a consumer would pay) may be negotiated down?
  5. Where rates are not publicly published, but other information usually included in lendingRates is available (for example, loan term), where in PRD should that information be included?

We have recently published guidance on Sharing product data in the non-bank lending sector which we consider would largely answer the questions raised. With respect to your specific questions:

  1. Please refer to the content in our guidance under the heading Highly bespoke products for information on when the isTailored flag can be used.
  2. Please refer to the content in our guidance under the heading How can information about interest rates be shared? for information on sharing single, from or range rates.
  3. We encourage data holders to share information about their products that is as accurate, complete, and useful to end users as possible. This could include sharing information that is made available to a consumer after they input specified information into a quote tool on a website. However, we recognise that some products are highly bespoke and require significant amounts of information to be provided by a consumer to determine pricing. In these circumstances, data holders may use the isTailored flag instead of sharing specific rates under CDR. Please refer to the content in our guidance under the headings Highly bespoke products and Products that are not publicly advertised for further information.
  4. Advertised rates should be shared as product data under the CDR. Data holders may note in an additionalInfo field that the rates may be negotiated down.
  5. As noted in our guidance, where the isTailored flag is used, data holders must still disclose other required product data about the product, such as information about product features, eligibility and constraints. Data holders should also disclose additional product data which would be useful to consumers. Without rates fields, additional detail may be provided in the following areas:
    • Product description field for anything that may be helpful as free-text. e.g. "Our home loan for sole traders is available at personalised fixed rates for terms from 1 to 5 years at up to 90% LVR, and a limit of $3 million dollars."

    • additionalInformation URI fields (or the additional... URI fields) to refer to other sources for additional information -

      • overviewUri
      • termsUri
      • feesAndPricingUri

      Some constraints types may also be relevant -

      • MAX_LIMIT
      • MIN_LIMIT
      • MAX_LVR
      • MIN_LVR
      • OTHER
21/05/2026 2690 Non-Bank Lenders multiple brand responses to Get Products

What is the expected response to Get Products when the same URL is used across multiple brands? For example we have NBL1 who is offering white label products under Brand1 and Brand2. As NBL1 supports both brands, they will use the same URL for Get Products for both brands. In this case it would be much easier for NBL1 to publish all products under one URL, especially if they have 30+ brands to manage. Is the intention that Data Recipients will get all products (for Brand 1 and Brand 2) when calling the Get Products for either of the brands? How are Data Recipients expected to differentiate between the products of the 2 brands?

We note the 'brand' field in the Get Products endpoint can be used –

  • as a query parameter - "Filter results based on a specific brand."
  • as a product field - "A label of the brand for the product. Able to be used for filtering. For data holders with single brands this value is still required."

At this stage we do not consider your stated approach is necessarily incorrect but we note it is uncommon. If you do decide to use the brand, brandName and brandGroup fields to differentiate products in one URI, it will be important to be mindful of accuracy and consistency, as the ability to use the brand to filter the endpoint response may produce incorrect results if filtering is used and there are mismatches.

Another option may be to have multiple different URLs resolve to the same backend. This would be consistent with the prevailing approach in the CDR (i.e. having a different product URI for each brand) and makes things easier should it become necessary to have different product data for particular white label products in future. In particular, this approach would have the following advantages:

  • Any changes wouldn’t be subject to propagation delays induced by the caching described in the Standards. This would be an issue were the URI to change.
  • The particular brand that is being queried would be captured, which may have some advantages.
21/05/2026 2655 Non-Bank Lenders

Phase 1 Product Reference Data (PRD) commencement mandatory requirements

  1. Are the Get Metrics, Get Service Status, and Get Outages APIs mandatory for Phase 1 PRD-only commencement, or are these obligations deferred until Phase 2 (Consumer Data sharing)?
  2. Is a Get Metrics endpoint mandatory for the ACCC to poll if we are only sharing unauthenticated product data? If so, what is the specific reporting frequency and data latency required for Phase 1?
  3. Do Phase 1 PRD endpoints (which are unauthenticated) still require a protected mTLS Admin Base URI for the CDR Register to perform health checks or collect metrics?
  4. Are we required to implement the Dynamic Client Registration (DCR) APIs during Phase 1, or can the registration of PRD base URIs be managed manually via the Participant Portal?
  5. Must we host OIDC Discovery (.well-known) and JWKS endpoints in Phase 1 if we are not yet performing consumer authentication?
  6. If using a third-party vendor for PRD, must we provide a separate Admin Base URI for ACCC metrics collection? Does this URI need to reside on our own owned domain?
  7. We understand the latency target for the Unauthenticated Tier is 1,000ms (p95). Aside from this and a minimum throughput of 300 TPS, are there any other mandatory NFRs to consider for Phase 1?
  1. Please refer to our recently published guidance on ACCC expectations for NBL compliance with Get Metrics, Get Outages and Get Status endpoints.
  2. As above, please refer to our recent published guidance on ACCC expectations for NBL compliance with Get Metrics, Get Outages and Get Status endpoints.
  3. As outlined in the article above, the Admin Base URI, which hosts the Get Metrics solution, is expected to be made available at the same time as consumer data sharing. There is currently no expectation for it to be made available during Phase 1 alongside the PRD endpoints.
  4. DCR is only required for Phase 2, when the remaining authenticated endpoints become available. PRD-only Data Holders are not required to implement Dynamic Client Registration APIs, as these APIs are used to register software products with the data holder for enabling data sharing, which is not obligated until Phase 2. Data Holders can use the CDR participant portal to specify their PRD base URIs.
  5. We do not expect that participants need to build the DCR APIs, JWKS endpoint, OIDC Provider Configuration endpoint, or any of the other mTLS/authenticated APIs as there are expected alongside the Phase 2 obligations for Consumer Data Sharing
  6. There is currently no obligation to provide an Admin Base URI during Phase 1, as the relevant obligations commence alongside Phase 2 Consumer Data Sharing.
    Additionally, you cannot provide a separate Admin Base URI exclusively for PRD. Even if you engage a third-party vendor for PRD, they would still need to ensure the metrics are consolidated and made available through the Get Metrics solution required under the Phase 2 obligations.
    Whether these endpoints are made available through your own domain or via a service provider domain is ultimately a decision for the participant. However, it is important to note that, when requesting certificates for mTLS endpoints, the Consumer Data Standards require the certificate Common Name (CN) to align with the organisation’s Primary DNS name and this is validated at the time of the certificate issuance that the CN matches your domain information.
  7. That’s correct; however, the Products endpoint is not classified as High Priority and therefore follows the unauthenticated tier requirement of 1500ms, rather than the 1000ms indicated.
    Please see the Non-functional Requirements in the CDR Standards.
21/05/2026 2703 General (DH) HTTP status codes in malicious traffic scenarios

Seeking to check the appropriate sequence of HTTP status codes for PRD GET APIs in a DDOS or malicious traffic scenario.

For example, initially where request volumes exceed NFR thresholds, the data holder applies rate limiting and returns HTTP 429 (Too Many Requests). If the traffic is then assessed appropriately by the data holder as malicious (e.g. DDOS) and the data holder decides to block the source at a gateway or WAF level (e.g. IP blacklisting), is it appropriate for subsequent CDR requests from those blocked sources to receive HTTP 403 (Forbidden)?		 The following article may cover your query: What constitutes a refusal to disclose required data?

I would suggest that for consumer data sharing, an accredited data recipient should never be blocked by IP address, as valid requests received must result in the requested required data being disclosed except in the circumstances noted in the guidance.
21/05/2026 2701 Energy (DH)

Redirect to App clarification

  1. Desktop initiated journeys
    If a consumer initiates the CDR consent journey on a desktop browser, and the data holder mobile app is available on a separate device:
    Is the expectation that the consumer continues the authorisation journey on the web (desktop), consistent with current flows?
  2. Mobile journeys – App vs Web behaviour
    Where a consumer is on a mobile device (either via browser or ADR app) and the data holder app is detected at the time of redirecting from ADR to DH:
    Should the data holder automatically redirect the consumer to the mobile app without presenting an option, or should the data holder provide the consumer with a choice between continuing via web or mobile app?
    Or is the redirect to DH App required only if the consent journey initiated from ADR App?
  3. Existing authenticated session vs new authentication
    In the context of Redirect to App:
    If a consumer is redirected to a data holder mobile app where an active authenticated session already exists, should the data holder reuse the existing authenticated session to continue the authorisation flow, or require the consumer to re-authenticate as part of the CDR process?
    Additionally, are there any expectations on how data holders should handle cases where the authenticated session may differ from the consumer who initiated the CDR journey?
  4. Customer dashboard (mobile app)
    Regarding the customer dashboard at the data holder:
    Is the channel (web versus mobile app) at the data holder’s discretion, with no additional requirement as part of the Redirect to App obligation?
  1. Generally, yes a desktop web flow may continue on desktop, but the data holder may support Decoupled Authentication to provide a better experience for customers (where the consumer can authenticate on mobile, then return to desktop). A mobile web flow would be expected to redirect to mobile app.
  2. The standards state: "If a data holder provides an app, the data holder MUST implement Redirect to App in accordance with the relevant consumer experience authentication and security profile standards."
    There are no provisions for asking the consumer the channel in which they would like to continue authentication, but if a data holder provides an app that the consumer doesn't have installed (for example by knowing an app didn't intercept the authorisation request) the data holder may invite the consumer to install the app first. See Common Authentication Standards.
  3. There are no standards explicitly preventing this, so it may be possible for an authentication to be assumed from an existing session, but it may also depend on the following:
    1. Could you re-trigger a biometric test, to verify that the current user is still the same person that was initially authenticated?
      1. In relation to this, you may need to consider detail related to Authentication levels and session activity/timing with respect to 'Reauthentication' in Digital ID.
      2. Would you be able to confirm that the existing session was authenticated to a level that would meet any requirements for CDR? (and if not, would a step-up be possible?)
    2. Could the user still access a profile selection feature for CDR purposes, if applicable?
    3. Would there be any impact to CDR metrics requirements in the authentication and authorisation flow?
    4. The standards currently state:
      1. The provided OTP MUST only be used for authentication for CDR based sharing and MUST NOT be usable for the authorisation of other transactions or actions.
      2. From a security perspective the intent may be similar for Redirect to App, so you may need to consider whether an existing authentication in a banking context is able to be used for CDR purposes, and vice versa. You may need to consider any differences for app and web sessions.
  4. The requirements for a customer dashboard are unrelated to the redirect to app obligations, so the channel of the dashboard is at the data holders discretion. More information on this in relation to the Energy sector is here - Offline customer guidance.
21/05/2026 2699 Non-Bank Lenders Brand Group
When we create a brand in the CDR portal we need to select a "Brand group". We have two options "BUSINESS LENDING" and "CONSUMER LENDING". What should we select as we offer products to both & do not have separate brands for consumers and business?

Brand group field
Please refer to the White Labelled brands in the CDR article for detailed guidance regarding the use of the optional Brand Group field.

Brand groups have been introduced to address significant changes in the demographics of data holder brands within the non-bank lending sector, specifically:

  • a dramatic increase in the ratio of data holder brands to holders; and
  • an increase in brand owners that have concurrent arrangements with multiple designated data holders (e.g. white label arrangements)

Brand groups are applicable in cases where brand owners have current arrangements with multiple data holders. If brand grouping is to be utilized, all relevant data holder brands should be assigned to the same brand group. Additionally:

  • the brand group should be immediately recognisable to the consumer
  • the brand group should be chosen to maximise the likelihood of a search match when selecting a provider

Next steps for consideration
We encourage you to consider whether the brand you are registering has an identifiable need to utilise the brand group field in line with the guidance. If you consider it is unlikely to be relevant, it is not mandatory to populate the field with information.

Should you determine that the brand group is pertinent to the brand you are registering, and if "BUSINESS LENDING" and "CONSUMER LENDING" are not suitable options, please enter a new value to establish a different Brand Group.
21/05/2026 2696 Non-Bank Lenders "isTailored" field in PRD
Is risk-based pricing alone sufficient to categorised a product as isTailored = true when a product, such as a personal loan or car loan, has risk-based pricing (i.e. where the interest rate is set based on the risk profile of the customer, and potentially other aspects, such as the type of car being offered as security?		 We have recently published guidance on Sharing product data in the non-bank lending sector. Please refer to the content in our guidance under the heading Highly bespoke products for information on when the isTailored flag can be used. The guidance also contains other information on how product data can be shared in the non-bank lending sector.
21/05/2026 2693 Banking (DH) BUY_NOW_PAY_LATER Product Category Implementation
Could you please confirm whether it is mandatory to implement the BUY_NOW_PAY_LATER product category as part of ACCC future dated obligations? Additionally, how should the organisation comply if this product category is not applicable?		 Recent amendments to the CDR Rules introduced new obligations for data holders offering Buy Now, Pay Later (‘BNPL’) products. For data holders in the banking sector, the earliest commencement date for CDR data sharing in relation to BNPL products is 13 July 2026. More information on data sharing obligations for BNPL products can be found in the Compliance guide for data holders in the banking and non-bank lenders sectors.

Under the CDR Rules, a data holder must share relevant product and consumer data for covered products that they offer, other than products for which data may be shared voluntarily. For more information on determining whether a product is a covered product, please see guidance on assessing whether a banking or non-bank lending product is in scope for CDR.

If a data holder does not offer Buy Now, Pay Later (BNPL) products, they are not expected to implement this product category as a part of their CDR obligations.

Note the Data Standards Body article on Data formats – schemas provides information about how to respond when data is unavailable.
21/05/2026 2691 Non-Bank Lenders Direct Debit
If a Data Holders pulls regular lease payments from their customers (CDR consumers) by direct debit, should DH's be supplying information about Direct Debits on the direct-debits endpoint, or scheduled-payments, or maybe neither?		 'Direct Debits' are where a third party has an authorisation to debit the account of the consumer, and 'scheduled payments' are payments going out of the account. These don't seem to fit your scenario.

These would just be shared as transactions (credits) coming into the NBL consumer's account, possibly with the 'type' specified as either INTEREST_PAID or OTHER. A bank for example, on the other end of these transactions would share them as either direct debits (or scheduled payments) from their consumer account depending on the instruction.
21/05/2026 Verbal Question 1 Banking (DH) We think there is a small inconsistency in the Consumer Data Standards (since the CDR Rules were amended on 04 March 2025). Prior to these amendments, a customer may have been able to share their customer data (and address book) without needing to select an account. With the change in Rules such that a customer MUST select an account we think the line in bold below should be removed from the Standard.
Section: https://consumerdatastandardsaustralia.github.io/standards/#authorisation-standards
Authorisation:
Account selection
Data holders MUST allow the consumer to select which of their accounts to share data from if the data request includes account-specific data and if there are multiple accounts available. The Data holder MAY omit this step if none of the data being requested is specific to an account (e.g. Saved Payees).
The provision in the rules is Clause 3.2 of Schedule 3.		 The DSB will take a look at clause 3.2 and compare that to what the Standard is saying to check whether the might be an inconsistency or not.
21/05/2026 Verbal Question 2 General (DH) As per the standards ID permanence, the identifiers must remain immutable across consents and sessions.
In cases where an arrangement is expired or revoked, should the data holder continue to retain or be able to reproduce the same encoded resource IDs (e.g. accountId or transactionId) if the same underlying resource is later shared again under a new arrangement for the same consumer or software product context?
Alternatively, if a new arrangement is created at a later stage for the same resource, is it acceptable to generate and use a new encoded ID instead of reusing the previously assigned encoded ID from the inactive arrangement?		 A similar question has been raised previously and some guidance on that is being developed at the moment.
21/05/2026 Verbal Question 3 Energy (DH)

Solar Sharer Offer (SSO) in CDR Energy Product Reference Data from 1 July 2026
We need to understand the DSB's position on how the SSO should be represented in CDR
Energy Product Reference Data published via Get Account Detail.

EnergyPlanTariffPeriodV2.timeOfUseRates[].type enum currently supports: PEAK \ OFF_PEAK \ SHOULDER \ DEMAND

None of these values can distinctly identify an SSO free-electricity period.

 Question taken on notice
21/05/2026 Verbal Question 4 Non-Bank Lenders Question raised regarding whether non‑bank lenders planning to go live ahead of the 13 July milestone could seek an exemption from the pre-July 13th reporting requirement, noting concerns that early reporting would be of limited value and may discourage earlier participation. The ACCC is aware of this issue and will respond later. There may not be anything preventing people applying for exemptions in those circumstances but a formal response to the question will be provided later.
16/04/2026 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.
16/04/2026 Verbal Question 1 Non-Bank Lenders

Resources available

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?
16/04/2026 Verbal Question 2 Non-Bank Lenders

Assessing whether a product is in scope

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.
19/03/2026 2632 Non-Bank Lenders

Merchant Names: How transaction information can be managed

There is one specific scenario that is both very important to NBLs and also appears to be in a grey area. It is as follows:

  • NBL wishes to use merchant information (which is not customer specific) to categorise the transaction
  • To identify the merchant the merchantName and merchantCategoryCode are passed to an Large Language Models (LLM) to make a recommendation on the likely type of transaction that would be made with that merchant
  • The LLM can make can initiate a web search to find information on that merchant to assist in the recommendation

The concern is not with the LLM, as models are available that can be run in jurisdiction and with no opportunity for the data provided to be shared with a third party. The concern is with the web search that the LLM might perform as this will end up using external web search engines with T&Cs that are not always conducive to the handling of CDR Data as per the rules.

By the time the web search occurs, the search query is going to be exclusively data that is essentially public (MCC and Merchant Name) and is in no way personal to, or attributable to, the customer.

Would the use of an LLM with the web search capability be acceptable under the CDR rules?

 We have provided general information below which may assist.

An accredited data recipient (ADR) is required to comply with privacy safeguard 6 (PS 6) in relation to CDR data for which there are one or more CDR consumers (section 56EB of the Competition and Consumer Act 2010 (the Act) and see section 56AI(3) for the meaning of ‘CDR consumer for CDR data’).

PS 6 only permits an ADR to disclose CDR data for which there is a CDR consumer to third parties in certain cases – for example, through an outsourced service provider (OSP) arrangement (see rule 7.5(1)(f) of the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules) and Chapter 6 of the OAIC’s Privacy Safeguard Guidelines which provide guidance on the meaning of ‘disclose’).

An OSP arrangement is not required if no CDR data is disclosed to a third party.

An OSP arrangement is generally required when an ADR discloses CDR data to an external party (such as an external web search engine), and a person is identifiable or reasonably identifiable from the CDR data or other information held by the ADR (see section 56AI(3)(c) of the Act). For more information on the relevant considerations when making this assessment, see the Explanatory Memorandum to the bill which introduced the Consumer Data Right, particularly from paragraph 1.103 and [B.97] – [B.105] of Chapter B of the OAIC's CDR Privacy Safeguard Guidelines.

We understand that some ADRs have implemented use cases that involve use of LLMs. You can refer to the Find a Provider page which provides a list of ADRs and their websites. The page also provides a link to each ADR’s CDR policy which may detail any OSPs the ADR uses to help implement such use cases. For guidance on OSP arrangements more generally, see the fact sheet on CDR outsourcing arrangements
19/03/2026 2662 General (DH) Unexpected success response when updating jti via PUT /register

We registering a client using the POST /register API. While updating the registration using PUT /register, we deliberately modified the jti value with a random string. In this case, the PUT /register request returns a successful response instead of an error, even though jti is an unmodifiable parameter, as it does not have a green tick mark in the CDS.

As you know, jti is a "Unique identifier for the JWT, used to prevent reuse of the SSA."

The jti value is expected to be a unique identifier for every JWT (see here), so the fact that you changed it, and it was accepted, would appear to be correct.

Your reference to the field being 'modifiable' appears to refer to the table in the Client Registration section.

As some of those fields are not part of the SSA itself, they are not really meant to be subject to the 'modifiable' statement - in particular for jti as the upstream standard requires it to change on every use. I understand that this can be confusing.

There is a standards maintenance issue to address this inconsistency, as outlined in statements -
19/03/2026 2664 Non-Bank Lenders Amending consent

As a designated NBL data holder, our existing systems currently support a revoke-and-recreate capability (i.e. within the standard amend CX journey, the consumer creates a new consent reflecting the amended details, and separately manually revokes the prior consent).

If the revoked and new consents are appropriately linked (e.g. via a common arrangement ID), would this approach satisfy the CDR requirements for consent amendment? Or is there a clear expectation that amendment must occur without requiring the consumer to revoke the original consent?

We can't provide specific implementation advice, but the following details are relevant to the amendment process -

  • Dashboard Standards

  • Specifying an existing arrangement (extract below)

    If a Data Recipient Software Product provides the cdr_arrangement_id claim in the request object to the Data Holder's PAR endpoint, the Data Holder MUST revoke any existing tokens related to the arrangement once the new consent is successfully established and a new set of tokens has been provided to the Data Recipient Software Product.

  • Revocations initiated by the consumer would normally require the DH to notify the ADR of the revoked arrangement ID. As the amended authorisation would be given the same arrangement ID as the original authorisation, a typical manual revocation notification to the ADR would cause them to revoke amended consent in the scenario you described.
  • As an amendment is not expected to involve manual revocation, your scenario may also impact Metrics reporting, in particular -
    • revokedAuthorisationCount: The number of revoked authorisations.

  • Most importantly and directly related to the scenario you propose, the rules state:

    4.24 Restrictions when asking CDR consumer to authorise disclosure of CDR data
    When asking a CDR consumer to authorise the disclosure of CDR data or to amend a current authorisation, the data holder must not do any of the following:
    (a) add any requirements to the authorisation process beyond those specified in the data standards and these rules;
    (b) provide or request additional information during the authorisation process beyond that specified in the data standards and these rules;
    (c) offer additional or alternative services as part of the authorisation process;
    (d) include or refer to other documents.
     

The standards do not support an experience where the consumer would be informed of a need to revoke an authorisation as part of an amendment.
19/03/2026 Verbal Question 1 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.
19/03/2026 Verbal Question 2 Banking (DH)

I would like to know if FDOs will be published for the Data Holders to start using the new versions of the following Register endpoints.
If not, is there a page where I can find information about when the existing versions will get retired?

  1. Get Software Product Statuses (V3)
  2. Get Data Recipients Statuses (V3)
  3. Get Data Recipients (V4)
 Register Implementation Schedule

There's not a specific FDO for calling those endpoints. They were essentially unchanged, but they adjusted some of the filters that were previously available that allowed their data recipient endpoints to be filtered by banking or energy, but those filters were never applied because all data recipients are kind of sector agnostic. Those new versions should be available now, but not sure if the ACCC has a plan for when previous versions may be deprecated.
19/03/2026 Verbal Question 2 follow up Banking (DH) I've gone through the change and it's specific to the sector related enumerated value message, but it will be good to know if there is any plan to retire the existing version so that we can prepare for the change to start using the new versions. To be followed up with the ACCC
19/03/2026 Verbal Question 3 Banking (DH) In the data standards there is the "Lending Adjustment rate - Penalty" field. Based on a sample of financial institutions, this does not appear to be in use. What did the Standards have in mind to be covered with this? I think the original intention was that if you have a loan and you don't make repayments, you may get a penalty (eg an extra half a percent rate) and that would be specified as a penalty adjustment for a lending rate.
19/03/2026 Verbal Question 4 Banking (DH) 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? To be followed up with the DSB
19/03/2026 Verbal Question 5 Energy When do AEMO anticipate they will have implementation dates for their API changes? How will these be communicated through to us?

The build phase is in progress our indicative delivery dates as of today are:

Pre-production July 2026
Production August 2026

Communications channels

  • MSUG - Market Systems User Group (Every 6 weeks)
  • Implementation Forum (Held Monthly NEM Reform Changes)
  • ITF - Industry Testing Forum WEM (Targeted dates as communications come available)
  • ITDF - IT Development Forum (Gas Markets Monthly)
  • AEMO Support Hub Bulletins closer to Go-Live dates

Special note the Legacy URL's and new URLs will run in parallel until late December 2026.
19/03/2026 Verbal Question 6 Non-Bank Lenders

First Question: Products with rate ranges.
I'm just keen to understand what the schedule is for the DSB and the Chair are to address support for products with rate ranges as it is a pressing issue for the viability and usability of the data once the PRD is published.

Second Question: Campaigns for NBLs that do short-term campaigns.
There are generally two approaches that NBL's are considering:

  1. When there's a campaign, they'll do a duplicate product just for that campaign. And they'll put an effective date, start date and end date and give it a new name, etc. So it'll appear in the PRD for a period of time with effective date and start date related to the campaign with eligibility criteria indicating eligibility and how you can apply for it under the campaign.
  2. Keep the product that is the subject of the campaign and just republish it with a new discounted rate with the appropriate additional info associated with it. And then when the campaign is over, they'll republish again and remove it. So effectively, as the campaign becomes available and then ceases to be available, the core product gets updated.

I just wanted confirmation that both of these seem completely viable under the DSB standards.

 The DSB and ACCC are currently in the process to responding to all the questions from the NBL workshop and will come back ASAP.
19/02/2026 2609 Non-Bank Lenders DH hosting the status and outage endpoints if only sharing PRD URI

For PRD only participants, they will only have PRD related endpoints (products and product details), is there any additional benefit in maintaining the status and outage endpoints if they are only sharing PRD versus just keeping two "static" pages so that they are "compliant"?

Previous guidance and comments are here:
19/02/2026 2629 Banking (ADR)

Testing with Data Holders - Production
 

  • How can a Data Recipient test each Data Holder brand connection to ensure it is working as expected without requiring a live test with a real bank account?
  • What is the recommended approach for validating connections across multiple banks before moving into production?

We are not be able to provide specific guidance as to a recommended approach but general approaches are:

There is more detail on testing in the following sources:

You may also find further insight into this situation on the following Standards Maintenance issue, where you can add comments to continue the discussion if you wish:
19/02/2026 2631 General (ADR) Consumer sharing their CDR data with a third party

After collecting a consumer’s CDR data, it is disclosed to the consumer by showing it to them on screen. Our interpretation of this article is that, as a next step, we can ask the consumer to give us their consent (a non-CDR consent) to provide their data (being no longer CDR data because it has been disclosed to the consumer) to a third party.

When asking for that consent we would make it clear to the consumer that in the hands of the third party their data will not be governed by the CDR Privacy Safeguards, but will instead be subject to the Privacy Act.

Does this interpretation align with the Third party data sharing use cases article?

The example you provided appears similar to scenario 1(c) in the Third-party data sharing use cases article, whereby:

  1. the accredited data recipient (ADR) first discloses the CDR data to the consumer as is permitted by rules 7.5(1)(a) and (d) of the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules)), such as by presenting the CDR data to the consumer in the ADR’s app/tool
  2. the consumer then decides to share their CDR data with a third party.

It is important that it is the consumer and not the ADR, who initiates this process and on-shares their CDR data with the third party.

As the consumer is not regulated by CDR, they can decide to share their data to whoever they wish. While CDR consents are not relevant to the consumer’s sharing of their data, the article notes the following:
 

Where a consumer shares CDR data outside of the ADR’s app/tool, it is critical that this be a result of an informed consumer choice. It is important that consumers understand the implications of this, and freely and voluntarily elect to that data being shared. ADRs should clearly explain to consumers that shared CDR data that leaves the ADR’s app/tool will be handled in accordance with any applicable privacy legislation such as the Privacy Act 1988, and that consumers should check the third party’s data handling policies such as their Privacy Policy.


In addition to or as an alternative to this, an ADR can seek a CDR consent in accordance with the CDR Rules (noting rule 4.12 restricts the seeking of CDR consents in certain circumstances). If an ADR wishes to disclose a consumer’s CDR data based on a CDR consent, it would be limited to the permitted uses and disclosures set out in rule 7.5 of the CDR Rules, such as those made under a disclosure consent.

Privacy

In your example, we understand the consumer would be sharing the data in a way in which it is taken outside of the ADR’s app/tool and is sent to the third party. Generally, the CDR privacy safeguards would not apply to the data that is in the third party’s hands however, other privacy laws such as the Privacy Act may apply depending on the third party’s circumstances.
19/02/2026 2634 General (DH) Changing Data Holder Endpoint name

When using the CDR portal to edit Production Details the only options are to "add" new endpoints, we cannot edit the existing endpoints. Does adding new endpoints replace the old endpoints?		 The update will be visible to the user after it undergoes review and approval.

Please add the new Authentication details using the "add" button on the endpoints configuration screen and then create a service request on the Management Portal (https://cdrservicemanagement.atlassian.net/servicedesk) or reach out to CDRTechnicalOperations@accc.gov.au for review and approval.

Once the new Authentication details is approved, the old one will get deleted.
19/02/2026 2640 Non-Bank Lenders Voluntary Data Sharing for non-individual accounts

Complex accounts are currently out of scope for Non-Bank Lenders. This includes business (non-individual) accounts. As such it is not defined who can initiate data sharing for non-individual/business accounts. Given this, is a non-bank lender able to voluntarily share consumer data for our business customers by allowing users with existing online access to initiate data sharing?		 Currently non-bank lenders (‘NBL’) are not required to respond to complex requests, or to provide services needed to be able to respond to complex requests. That is, the implementation date for complex requests in the non-bank lending sector has not been set in the CDR Rules.

Treasury is actively considering the timing for commencement of obligations in relation to complex requests for non-bank lenders and is expected to consult on proposed rule changes in 2026. Relevantly, we note Treasury has previously consulted with industry on proposed changes to nominated representative rules.

Treasury has advised that the policy intent of carving out complex requests for now is to avoid unnecessary or duplicative compliance burden for how NBLs may be required to comply with this obligation in the future. Therefore, there could be a risk of unnecessary build for NBLs bringing in capability to respond to complex requests (including requests on behalf of non-individuals) early.

Once there is a commencement date available for complex requests in non-bank lending, it would be open to you to comply with these obligations early.
19/02/2026 Verbal Question 1 General (DH) Gathering metrics separately for product versus consumer request implementations

In the recent changes to the product API as V7, which introduced the brand name for the white labelling change. We also got new product based URI which is being split from the public based URI which allows for separate technical implementations for product versus consumer requests. But the metrics in getMetrics are still tied together (unauthenticated and authenticated), there's no separate product invocation metrics. Is the ACCC going to make any allowance for data holders that are actually having physically separate implementations or different product brands that don't align with consumer request brands?		 ACCC request that this be raised in the CDR Support Portal for a response post meeting.
19/02/2026 Verbal Question 2 Energy Planned AEMO changes

Regarding Energy Industry, we've recently been made aware of changes that AEMO have planned to make. Our reading of this is that there is no impact to the CDR. Specifically, some of their endpoints scheduled changes. Is this view shared amongst this group?		 ACCC will follow this up with AEMO
19/02/2026 Verbal Question 3 Non-Bank Lenders Risk based pricing guidance

For NBLs with personal loans that have risk based pricing the guidance we had for PRD was to emulate CBAs personal loan product where min/max/indicative rates are all included.

The standards have no way to separate these rates systematically. They all simply look like optional rates making the use of the data impaired.

Will there be a change to the standards considered to fix this?		 ACCC and DSB have been talking about some of these issues and are looking at what the standards say at the moment and what guidance we might be able to provide that might set out some options for some of these scenarios.

There is a plan to have a NBL workshop in March, so there should be some information coming out about that soon to talk through some of these issues. After the workshop we will gather more information from the industry to understand it further before hopefully putting out some guidance.
19/02/2026 Verbal Question 4  General Maintenance Iteration changes

Maintenance Iterations 23 & 24 were no longer proceeding. Is there any more news on how change will be managed in future?		 This has been looked at inside the DSB in terms of our long term cadence behind managing change. We are planning on a consultation to work out the future state of that, we are looking to reduce the frequency of standards changes just to make it a bit easier for industry to manage change. MI23/24 is no longer proceeding but the items have been added back in to the backlog for future consideration.

Participants can still raise changes using the regular process via GitHub maintenance which will be considered by the DSB

Comments

0 comments

Please sign in to leave a comment.