• Get Products v5
• Get Product Detail v7

• Change log
• Future Dated Obligations

• Consultation hub

• 17 April 2026 Newsletter
• Subscribe

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?

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

• 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."

• 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.

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.

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.

• 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)

• 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

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