2025 Implementation Call Q&A

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 2 weeks 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	Question	Answer
04/12/2025	2608	Seeking some clarification on the CX guideline updates that were released in September 2025, such as Amending authorisations & Authorisation to disclose. Within the guidelines there is no date stated by which the changes need to occur - hoping to get more information around this.	Since the CX Guidelines (obligation type) are an an optional best practice example of a key requirement or recommendation, they don’t have an obligation date. However, the CX Standards do. I have gone through the Change Log for Authorise: Authorisation to disclose v1.35.0.2025.09.24 and Authorise: Amending authorisations v1.35.0.2025.09.24 and double checked the noted standards changes for any obligation dates. I have outlined it below. Authorise to Disclose Default example new checklist item: 3AU.00.28 — Decision Document 369 notes that the data standards outlined in the document (aside from 4.3 Redirect to App and 5.2 Authentication Flows) takes effect the day after publication on CD369. updated checklist item: 3AU.02.14 — Data Language Standard updated to include the non-bank lending sector. For obligation dates, please refer to Division 6.1, Schedule 3 of the CDR Rules updated checklist item: 3AU.02.24 — Same as above re: updated Data Language Standard Unavailable accounts updated checklist item: 3AU.03.05 — This reference was retired because it is not applicable to this flow. The standard remains in force in other places. Selection functionality new checklist item: 3AU.05.07 — This standard was also introduced in Decision Document 369. If the consumer authorises on the data holder app, this standard is in effect. This may occur in scenarios such as Redirect to App authentication and decoupled authentication. See page 2 on the decision document for more details on obligation dates. Amending authorisations Default example new checklist item: 3AU1.00.27 — Decision Document 369 notes that the data standards outlined in the document (aside from what is noted in the table under Obligation Dates on page 2) takes effect the day after publication on CD369. updated checklist item: 3AU1.02.14 — Data Language Standard updated to include the non-bank lending sector. For obligation dates, please refer to Division 6.1, Schedule 3 of the CDR Rules updated checklist item: 3AU1.02.25 — Same as above re: updated Data Language Standard Unavailable accounts This section was created to show an example of accounts being unavailable when amending an authorisation to disclose. The standards referenced in this section were introduced v1.11 or earlier so they already apply. For context, this section was created from Change Request 702: CX Guidelines - Required and voluntary data - Authorisation The CX Guidelines are optional to follow, but the CDR rules require CDR participants to have regard to them. The CX Standards differ in that they are binding data standards that must be followed.
04/12/2025	2610	Some of the mandatory claims in the ID token are name, family name, given name. But then there is a requirement that the ID Token should not include PII claims, and names are PII. Could you clarify the misalignment?	Some of what you've referred to as mandatory claims relate to the userinfo endpoint. ID tokens must not contain PII.
20/11/2025	2607 - 1	Personalised pricing for non bank lenders (pre-submitted question) Non bank lenders frequently have personalised pricing. The rate for the product depends on tens of parameters. As such, there is no single rate for the product. However, BankingProductLendingRateV3 has a mandatory field for rate, which is a RateString. This is a single number as a percentage. This prevents a range to be entered. Will there be changes to this standard prior to NBL go-live, or will there be further guidance on what number should be used (cap, collar, mid-point, other)?	This issue raises the same concern as #707 - Change to BankingProductLendingRateV3 to support a RANGE. There is no final proposal or direction on any changes in relation to that scenario, but there is feedback and options outlined in the discussion on that issue that you may find useful.
20/11/2025	2607 - 2	Campaigns and special offers (pre-submitted question) Non bank lenders frequently run campaigns for discounted rates/fees/etc. These often provide specialised rates based on the specific asset or individual for which the loan is being originated. A given product (e.g. car loan) can have multiple campaigns running at a time (e.g. a discounted rate for a specific car make/model for a 2 month campaign). The standards do not easily allow the discounts/rates/fees for the special pricing to be tied to eligibility (specific make/model of car). Are there planned changes to the standards to allow for this common non bank lending feature, should special offers be excluded or will further guidance be provided on how this should be handled (e.g. to duplicate products for each in-flight campaign)?	The ability to tailor product detail for a campaign may be done at various levels, including – Creating a new one-off standalone product completely customised for the campaign: Fully customised product for a campaign, potentially with effectiveFrom, effectiveTo detail Amend an existing product with some changes to: Eligibility detail For example, the OTHER eligibilityType with additionalInfo Fees Fee discountType if applicable, and discount eligibility details Rates Additional rate type (e.g., DISCOUNT) and applicabilityConditions
20/11/2025	2591	Third-party data sharing use cases In relation to the Third party data sharing use cases article - Can the consumer set up ongoing disclosures for a period of time e.g. 12 months, or does each disclosure require a new consent/action by the consumer?	Assuming that ‘new consent/action by the consumer’ is referring to the consumer’s intervention for scenarios 1(a)-(c) (enabling the consumer to share their data with a third party) and the consumer’s instruction for scenario 2 (allowing the ADR to disclose the consumer’s data to the consumer by sending it to an account the consumer holds with a third party). That is, we understand you are not referring to a consent as defined in the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules), such as a collection or use consent. Under either scenario - it would be open to an ADR to allow a consumer to set up an ongoing disclosure to facilitate data sharing in the way described for a defined period of time. This is providing the ADR has the required collection and use consents to provide the requested good or service under rules 7.5(1)(a) and (d) – noting that generally, ADRs can only seek CDR consents for up to 12 months at a time or up to 7 years for some consents provided by a ‘CDR business consumer’ (see rule 4.12).
20/11/2025	Verbal Question 1	Could we please get an update on the MI cycles eg dates of when we should expect the consultation papers related to MI23 & 24, dates when MI meetings will resume?	There are no confirmed dates for Maintenance Iterations going forward as we review the approach for how changes are submitted, assessed and prioritised. Information will be communicated when there is further updates. At the moment the current planning is to have non-breaking changes from MI23/24 open up for consultation by the end of the year and breaking changes consultation in early next year.
06/11/2025	2606	Get Account Details v4 March change For Get Account Details v4 DP#338 Decision Paper Banking Products and Accounts, under Eligibility, Features & Constraints, the fifth item listed states for the change:   Make the following breaking change (change of format) to address the related aspects of issue #595 - Use of additionalValue field in Product Eligibility Types. Update and align the requirements in the ‘Use of additionalValue Field’ descriptions associated with the two sets of PENSION_RECIPIENT and STUDENT ‘Eligibility’ enum values. Change affects the Get Product Detail and Get Account Detail endpoints due to their common schema. Can you please confirm if this change is actually for Get Account details OR only Get Product Details?	The Get Product Detail endpoint includes the eligibility object which refers to Product Eligibility Types. Both Get Product Detail and Get Account Detail include the fees object which refers to fee discounts and then fee discount eligibility. This object refers to Product Discount Eligibility Types. The change in #338 was to update and align the PENSION_RECIPIENT and STUDENT detail in both Product Eligibility Types and Product Discount Eligibility Types.
06/11/2025	2595	Rate range in BankingProductLendingRateV3 Many of the non-bank lenders will quote a rate for a lending product based on the assessed risk of the specific applicant. This means that the products essentially have a rate range (dependent on credit worthiness) rather than a specific rate. The IP used to assess credit risk is also very proprietary. How should this be handled in PRD when the specifics of the applicant is not known? Should the minimum rate (offered to lowest risk applicants) be used? Should the tailored flag be set?	This topic came up in the last maintenance iteration through this issue - #707 - Change to BankingProductLendingRateV3 to support a RANGE. During the iteration, some banking participants suggested that previous guidance or a consensus among participants was that for a product of that nature, the highest rate should be specified, with detail noting that the actual rate may be lower based on application details (as opposed to the other way around). The use of the isTailored flag was also discussed, but that flag typically means that no rate detail would be made available at all, which may not be desirable. No final position has been put forward on issue #707, so if you have any other suggestions or preferences from the options discussed, please add a comment for review.
06/11/2025	Verbal Question 1	Please can you point me in the direction of the information that a (DH NBL) needs to provide to start their registration on the CDR Portal	Guidance on how to apply to become an accredited data recipient or register as a data holder under the CDR: https://www.cdr.gov.au/for-providers Guidance for on-boarding for data holders: https://www.cdr.gov.au/for-providers/on-boarding-for-data-holders CDR Participant Portal user guide: https://www.cdr.gov.au/resources/user-guides/cdr-participant-portal-user-guide
06/11/2025	Verbal Question 2	Are there any recommended vendors for CDR?	No details about vendors for CDR
06/11/2025	Verbal Question 3	Under the fees ENUM for Product Reference Data there is no fee type of third party fee and are forced to use "other", is that correct? There is a requirement to capture the fees that are associated with product reference data and there is no ENUM type of third party fee. Is there any work that's being done on adding that as one of the ENUM because it will be commonly used? (eg Broker service fees, channel fee)	Response from an attendee on the call: Once the money gets charged to the account, how that is recovered by the financial institution is not really relevant to the ADR. It is more about the purpose, mechanism and other characteristics of the fee that matter, not the mechanics of where the money goes (eg upfront fee). An example a fee is passed on to a customer that is the same fee from the titles office for a mortgage but is just called the functional meaning of the fee such as a state titles fee, not the mechanics that go on behind the scenes. Event and Upfront are both in the CDR ENUMs so could both be options. If there are a lot of fees in the product (eg 5 of them were broker fees and another 5 were some other third party fee) then there may be a case to raise a change request and have a new type that would catch those common things that happen frequently which would be more useful for data recipients. Some references to some previous requests and discussions about different fees and fee types and how they can be presented: Product Fee Types #285 - Product Ref Data - leeway within standards makes fee comparison difficult Comment 1 Comment 2
23/10/2025	2587	SLA requirements Are there any specific SLA requirements that apply to lenders for updating product information published under the Consumer Data Right?	While there are no specific time frames for product data to be updated, the CDR standards require the following in relation to data quality: “If a Data Holder of CDR data is required or authorised under the Consumer Data Rules to disclose product data, the Data Holder must take reasonable steps to ensure that the product data is, having regard to the purpose for which it is held, accurate, up to date and complete. Data Holders are required to be able to demonstrate that reasonable steps to maintain data quality of product data are being undertaken.” This broadly mirrors Privacy Safeguard 11, which requires data holders to take reasonable steps to ensure that consumer data is accurate, up to date and complete. For the purposes of Privacy Safeguard 11, the OAIC has published guidance on what is considered reasonable steps in paragraphs 11.34 – 11.36, Chapter 11 of the OAIC Privacy Safeguard Guidelines. The guidance states that relevant factors to consider include the nature of the entity, adverse consequences if the quality of CDR data is not ensured and the practicability of taking action, including time and cost involved. We consider these would also be relevant to participants consideration of what reasonable steps to take to ensure product data is accurate, up to date and complete, as required by the above-mentioned standard. In the case of product updates, data holders may want to consider building into their product update process mechanisms to ensure that CDR data is ready to be updated as/when those other changes go live. ACCC note that what is considered reasonable will depend on the circumstances of a particular scenario. CDR participants may wish to seek their own advice on how best to comply with their CDR obligations.
23/10/2025	2593	Clarification on Data Holder's sharing voluntary data Can DH share data determined as voluntary data based on Compliance Guide for Data Holders - Banking and non-bank leaders sector? In the guide, it says DH may disclose voluntary data. However the answer given in this article (participant ADR as "https://cdr-support.zendesk.com/hc/en-us/articles/5478272146703-Sharing-required-and-voluntary-consumer-data" says DH can not share voluntary data?	We may try to clarify that article, but it is not saying that a DH cannot share voluntary data. Although the question was about energy data, the answer is applicable to all sector data holders. The question was asking what a DH should do if an ADR requests more data than the DH is able to disclose, particularly in the context of historical data. The questioner suggested two options - reject requests asking for more data than is available respond with the required data that is available. The answer was to provide the required data that is relevant to the request, and not to reject requests only on the basis that they may ask for more data than is available. The ADR may not be aware of whether the DH is offering voluntary data or not, and they may request more than the required limit if this is what the consumer has consented to. Some DHs may offer voluntary data and some may not, and some consumers may not have more than the minimum required.
23/10/2025	Verbal Question 1	Issue with Implementation Call meeting invites Having issues with no meetings coming through upon registration.	After registering, there is an additional option to download calendar events. If you have already registered you can access this option through the 2025 Implementation Call Series page, sign in or get a personalised link by scrolling down to the bottom of the page and click "update registration", fill in your name and email address and click "Email Registration Link". An email will be sent to your mailbox, in the email click "Change Registration", a new page will open, click "OK" at the bottom. The next page will have an "add to my calendar" option. Once clicked you will have an option to select the calendar provider to email the invites to. For any issues feel free to email [e-mail] for assistance.
09/10/2025	2585	Redirect to app clarification on CX requirements In the existing CX standards for authentication, we need to provide a link to CDR policy. Hence, wanted to check if the CDR policy need to be provided during ‘redirect-to-app’ and if there is a CX recommendation on the screens that should have this link.	CDR Rule 7.2(8) (aka CX Checklist ref 2AU.00.01/annotation #1 on the Redirect to Web with One Time Password) is accompanied by the a CX Guideline 2AU.00.17 (or annotation #17 which states that:   Data holders should consider including their CDR policy in the authentication process as this will likely be the first online service the CDR consumer uses to interact with their data holder for the purposes of CDR. Therefore, including the CDR policy during the authentication process is recommended but not mandatory. This inclusion may be more beneficial during a Redirect to Web with One Time Password authentication process, as consumers may spend more time interacting with these screens compared to when using a Redirect to App method. CDR Rule 7.2(8) can be satisfied if it’s readily available through each online service by means of which the CDR entity (or rep) ordinarily deals with the CDR consumer. CX Guideline 3AU.02.20/annotation #20 in Authorise to Disclose also recommends including the CDR policy in the Authorisation flow.
09/10/2025	Verbal question 1	Deregister a brand for product data When someone tries to list products from the product API endpoint for a brand that does not have any products on the endpoint (as they are listed under the parent's brand product API rather than listing the products twice), they just get a 200 OK (request succeeded) and an empty array. Would it be possible to deregister that brand for product data.	There is some detail related to that situation in Consultation Draft 376 about white labelling. It would address the ability to switch off PID sharing where it's not applicable.
25/09/2025	2582	Clarification on scope of holder of key / certificate-bound access token requirement For the admin APIs, in particular GET /admin/metrics, should this endpoint require a certificate-bound access token? i.e. should Data Holders expect that the certificate presented by ACCC in the token request and bound to the token, matches the certificate presented by ACCC in the subsequent GET /metrics request?	That is the expectation, as the admin endpoints require MTLS.
25/09/2025	2581	Expectation of how long entries remain on the Status endpoint There are several DHs at the moment that appear to have very out-of-date entries being returned via their Get Status endpoints. Please confirm our understanding that Get Status should only be used for reporting active issues.	Get Status is only expected to show current impact. For example, the standards description for the status field includes:   SCHEDULED_OUTAGE: (an advertised outage is in effect). The Outages endpoint is also only expected to include future-dated scheduled outages. It seems as though these endpoints may be misconfigured and showing all entries.
25/09/2025	Verbal Question 1	When are the consultation papers for MI23 & MI24 going to be available please	We have received feedback from the Chair on MI23 to focus on the NBL sector as they come on board, so we are revisiting the scope that will go out for consultation which has not been finalised yet which is causing the delay. We are hoping to finalise that scope and have consultations open in early October. MI24 is unlikely to be scheduled this year while NBL whitelabelling consultation takes place. But this is yet to be confirmed.
11/09/2025	2496	Clarification on Transaction Security Update - Cipher Suites Compliance Can you confirm whether, after 17 March 2025, Data Holders are required to support all ciphers recommended in the BCP 195 documentation, or do they have discretion in selecting which ciphers to support? Specifically, would it be acceptable for a Data Holder to support only the following two cipher suites from the BCP 195 list? TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	Based on the current status, it is likely to be acceptable to only support those cipher suites as they are two of the four recommended, and section 4.2.1. Implementation Details of RFC9325 states "Clients SHOULD include TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 as the first proposal to any server."
11/09/2025	2499	Clarification on disabling the hybrid flow and allowing only the ACF Do the standards recommend any specific error code & error description if an ADR attempts the Hybrid flow auth call OR are we ok with http error response 400 with a meaningful error message? Do we also need to error out hybrid flow DCR requests? We currently still have ADRs registered with us as hybrid flow profile. Are they supposed to do a DCR delete and re-register with us with ACF profile? OR Their profile will stay as-is just that their authorization call will be ACF? Do we as DHs need to take any actions on these profiles? ACF has been mandated for Data Recipients post 12th May 2025, so if we go live with this change earlier then we will need to error out the hybrid flow authorization calls specifically for those ADRs	Please refer to the standards. There are no error codes specific to this scenario in the standards as the normative standards apply. In this case I think you may be referring to [PAR]. After 12 May 2025, hybrid flow should not be supported. ADRs should not delete their registration, as that would trigger arrangement revocation at the DH. They should update their registration via the Update DCR endpoint. You may wish to encourage ADRs to update their registration if they intend to continue sending authorisation requests. It should be possible to support both flows until hybrid is retired. Negotiation of supported types is handled through the discovery document, PAR and authorisation endpoints.
11/09/2025	2552	DigiCert ONE Transition & Compatibility Clarification regarding the upcoming transition to DigiCert ONE platform and the issuance of new Intermediate CA ("CDR Intermediate CA 2025") for the ACCC issued certificates. For upcoming renewal: Will we receive only a new ICA-signed certificates from new platform, or will we receive 2 certificates one from old platform and another from new platform? How is backward compatibility ensured for Data Recipients during the transition period or is there an expectation that data holder must update trust stores or validation logic? Will a test environment with the new certificates be available for testing and if so when would it be available? Is there ACCC recommended approach to handle multiple certificate validation for same domains or Is ACCC coming up with a new guidance?	Please follow this link for more detail information into transition to DigiCert
11/09/2025	2576	Clarification of rules around Tokens and Claims v1.32 of the standards had a rule within Hybrid Flow requirements stating: "The ID Token returned from the Authorisation End Point MUST NOT contain any PI claims." With v1.33 this moved into the Baseline ID Token Requirements and now states: "ID Tokens MUST NOT contain any PI claims" The original rule was limited to a specific portion of hybrid flow (authorisation endpoint), because the ID token would be sent in a less secure way, but there was no such restriction on the ID token that was obtained later in the workflow where it's directly given to the ADR in an MTLS connection. That later stage (token endpoint) was similar for both hybrid flow and code flow and was even explicitly expected in this Zendesk article With the PI rule moved to baseline requirements, this changes to make it also apply to the token endpoint id token.	This change occurred as part of retiring Hybrid Flow in v1.33.0 as a result of issue #666, which was included in Maintenance Iteration 21. As of 12 May 2025, hybrid flow is no longer supported. There are some notes in the Version Delta here.
28/08/2025	2574	App2App Authentication Requirements Could links be shared on the finalised approach for App2App authentication requirement in terms of the credential level required to be met for CDR access	Below are the sections of the standards you can read to understand the requirements for enabling redirect to app (R2A) based authentication/authorisation: Authentication Schedule: It covers the general terms and timeframes for mandatory implementation of various R2A related components. Note that voluntary implementation is at the DHs discretion (can go live tomorrow if they like). CX requirements: CX Authentication Standards and CX Authorisation Standards InfoSec requirements: Authentication Flows->Redirect to App Levels of Assurance (LoAs) Credential Requirements I would also suggest reading the explanatory document (ED) for the approved changes which provides more context. It would also be worth keeping an eye on change request 700 where draft CX guidelines for Redirect to App will be published in the coming days for review.
28/08/2025	Verbal 1	Change in the signer to DigiCert1 I just wanted to be clear about the changes a data holder needs to make. My interpretation of the changes that we have to make is that we just package the server side certificates up as we normally would with the root ACCC certificate and the DigiCert1 intermediate certificate and the actual certificate that is for the server side. Is this a correct understanding?	Yes, that's correct as long as you are using both certificate trust chains now. So for client connections coming in when a data data recipient is connecting to the data holder and they're presenting their client certificate, they might present a certificate from the old platform, the MPKI 8 platform or the DC1 platform. So you need to trust two trust chains. So when accepting certificates when accepting client certificates, we need to be able to accept both those chains. But on the server side, it's one chain or the other. So you only need one service certificate. So either you have your existing certificate from the existing platform or after October and you renew your certificate, you'd get one from DC1 and you only have to support one service certificate at a time.
14/08/2025	2337	Discovery of public DH endpoints for Energy The authoritative way to discover public DH endpoints seems to be by manually accessing a PDF file from the AER web site. The URL for this resource has changed multiple times requiring manual work to regularly find and check the file. Is there a way to have an authoritative source of this resource that is programmatically accessible?	The DSB is exploring options to address this, and there is a maintenence issue related to it - Update Register API to return separate PRD and status/outage endpoint.
14/08/2025	2384	jwt-based response when cancel authentication When implement PAR request, and we only support code in response types, when the ADR sends invalid response_type, and we should return an error. Should it be JSON format error like describe here: https://www.rfc-editor.org/rfc/rfc9126.html#name-error-response? Or it should be a jwt-based?	The error should be a JWT as stated in the normative standard -   2.3. Error Response The authorization server returns an error response with the same format as is specified for error responses from the token endpoint in Section 5.2 of [RFC6749] Where the response type is code and mode is jwt, FAPI also requires JWT responses as specified by JARM.
14/08/2025	2460	Additional Service Point Data in Service Points APIs Could the below be considered for inclusion in future versions of the API? Transmission/Marginal Loss Factor (TLF/MLF) Transmission Node Identifier (TNI) (related to the MLF) Metering Data Provider (MDP)	The loss factor information (first two points) is likely to be included in the EnergyServicePointDetailV2.distributionLossFactor object. MDP was originally proposed to be included but was removed based on feedback from AEMO noting that most participants would only be interested in Financially Responsible Market Participant (FRMP), Local Network Service Provider (LNSP) or Distribution Network Service Provider (DNSP). If there is a need to have MDP included we would need to raise a change request via the maintenance iteration process.
14/08/2025	2551	SMSF Product Can you confirm if Non-Banks are required to supply SMSF-related products, e.g., SMSF Mortgage product? The existing Banking CDR Products seem to exclude any SMSF Mortgage products.	Our understanding is that a SMSF is a type of trust that may have either individual trustees or a corporate trustee. Whether an initial or large non-bank lender would have CDR data sharing obligations for SMSF accounts depends on two factors: who is the relevant CDR consumer for the SMSF product (i.e. whether an eligible CDR consumer is an individual or non-individual); and whether the SMSF product is a CDR ‘covered product’ and therefore CDR data sharing is required. Individual or non-individual consumer and their related consumer data sharing obligations Where the eligible CDR consumer for the relevant account is an individual, consumer data sharing obligations may apply to initial and large providers in regards to covered products according to the timeframe provided in the CDR Rules (see section 3.2.1 of the Compliance guide for data holders in the banking and non-bank lenders sectors). Where the eligible CDR consumer for the SMSF trust account is a non-individual or partner in a partnership, the CDR consumer must appoint a nominated representative before consumer data sharing related to that account can commence (see Trusts and nominated representatives in the CDR). However, data sharing obligations do not currently apply to complex requests for data holders in the non-bank lenders sector. This includes consumer data requests that are made on behalf of a CDR consumer that has a nominated representative (see section 3.1.1 of the compliance guide for guidance on complex requests). This means data holders in the non-bank lenders sector do not currently have consumer data sharing obligations in relation to products held by consumers who are not individuals or a partner in a partnership. The explanatory statement notes that the policy intent of carving out complex requests is to avoid unnecessary or duplicative compliance burden for how non-bank lenders may be required to comply with this obligation in the future. Covered product In relation to whether a SMSF product is a covered product, we refer to the article on assessing whether a banking or non-bank lending product is in scope for CDR. Under the CDR Rules, a banking or non-bank lenders product will be a ‘covered product’ if it satisfies the below three factors: the product is generally known as being a type of product listed in clause 1.4 of Schedule 3 of the CDR Rules, the product is publicly offered by or on behalf of a data holder, and the product is offered to consumers through a standard form contract. Initial and large providers in the non-bank lenders sector are required to disclose product and consumer data for covered products in accordance with the timelines set out in clauses 6.4 and 6.5 of Schedule 3 of the CDR Rules (except for products listed in cl s 3.1(2) and 3.2(3) of Schedule 3 of the CDR Rules). If a product is not a covered product, no CDR product or consumer data sharing obligations apply for that product. We note that data holders are responsible for compliance with their CDR obligations. The information contained in this response is guidance only and does not constitute legal advice. We suggest you obtain independent legal advice where necessary.
14/08/2025	2563	nppPayload - Service In relation to New Enums for Voluntary disclosure of additional service overlays #664: Can Service be null if nppPayload has data within it? There are old transactions where this field currently doesn't have information, and would like to know what is expected - a 5xx error or can we add in the null value?	You cannot provide a null for a mandatory field. Some related guidance - Handling transaction detail extended data when NPP is not supported: 404 Get Transaction Details Error Returned
14/08/2025	2566	Guidance on Rule 4.26(1)(h) part 4, Division 4.4 The rule states: (1) An authorisation to disclose particular CDR data to an accredited person expires at the earliest of the following: (h) if the authorisation expires as a result of the operation of a provision of these rules that references this paragraph. Note: Clause 7.2 of Schedule 3 is an example of a provision satisfying paragraph (h). This relates to when an accredited data recipient of CDR data becomes instead a data holder of that CDR data. Is the “authorisation to disclose” in respect to this rule referring to disclosure consents? So if we had collected disclosure consent, it would expire once we act as a DH instead of ADR for that data sharing arrangement?	The intent of rules 4.14(5), 4.26(1)(h) and clause 7.2 of schedule 3 is that accredited bank or non-bank lenders who become data holders of CDR data because they satisfy the conditions in clause 7.2 of schedule 3 should still be able to: continue collecting CDR data where a collection consent and authorisation is in place, and use or disclose the data as a data holder. On that basis: relevant collection consents and authorisations remain current for the period consented to / authorised by the CDR consumer use and disclosure consents expire, however the relevant person can continue to use / disclose the data as they ordinarily would as a data holder. This allows accredited persons to continue to collect CDR data and hold it as a data holder where the conditions specified in clause 7.2 of Schedule 3 of the CDR rules are met, and then use / disclose the data as they ordinarily would as a data holder. Treasury is currently considering how this can be clarified in a future version of the CDR rules.
14/08/2025	2571	CDR Specifications not matching deployed API The current CDR standards reference that the latest Endpoint version is 2. Calling https://api.cdr.gov.au/cdr-register/v1/banking/data-holders/brands/summary using x-v: 2 returns an error. However x-v: 1 returns the expected result. How do you determine what version is deployed?	The standards always show the latest specification available, but as these are generally defined as Future Dated Obligations (FDOs) the latest version specified will not necessarily be the version made available by a participant at that time. The FDO table explains the obligation dates for particular versions. The versions and dates of ACCC obligations (in particular Register endpoints) are not defined in the FDO list, but the endpoint version schedule provides detail of all versions and their associated dates. As the page notes, the ACCC will provide details of availability in due course, as noted here. Where an unsupported version is requested, the standards state that participants MAY provide detail of the versions supported through the error response, but it appears the Register does not currently do this.
14/08/2025	2573	Register APIs implementation dates CD367 has mentioned updates to “Register” APIs. When will the new version be implemented and the old ones demised? Would we receive any separate communication on the same, or if it’ll be published on github?	The Standards will sometimes show future versions of endpoints that participants are required to make available by a Future Date (an 'FDO'). This is the same for future versions of Register APIs. The date details for all endpoints are shown in the following sections: Register Implementation Schedule Endpoint Version Schedule The Standards do not specify obligation compliance dates for the Regulator, so these are provided separately by the ACCC.
31/07/2025	2413	X2App Interaction flows Is there a proposed ETA of when would X2App be an accepted interaction flow for a data holder instead of the current OTP-Redirect interaction flow?	Decision #369 includes detail for Redirect to App flows. This decision is now incorporated into version 1.35.0 of the standards.
31/07/2025	2486	Transaction security ciphers The transaction security talks about MTLS and Ciphers. Do we have to apply these ciphers for the unauthenticated endpoints products, products details, status and outages?	The Transaction Security section notes Endpoints for transferring CDR Data that are classified as not requiring authentication (i.e. public endpoints) or those specified as TLS, MUST NOT use [MTLS]. The endpoints you noted, all state "This operation does not require authentication." which means they are public endpoints, and therefore TLS only. The Ciphers section applies to both TLS and MTLS, but note that the requirements changed from March 17th 2025.
31/07/2025	2511	Deprecation scheduled for Banking Transaction Details V1 API How long must the Banking Transaction Details V1 API be supported by Data Holders?	Decision #364 has now confirmed the date from which Data Holders may retire Get Transaction Detail v1 as November 10, 2025.
31/07/2025	2519	Admin APIs - Metadata Update Are Data Holders required to support use of the Metadata Update API? The GitHub issue #53 "Adopt Data Holder metadata update support" remains open for consultation and details that the CDR Register design will not support Data Holder Metadata updates.	The Metadata Update endpoint is currently defined in the Standards, but the ACCC Register has not yet adopted that mechanism for communicating changes with participants.
31/07/2025	2528	Handling Multiple constraints of the same type in GET Product Details For Get Product Detail v5, we have identified that some of our products have multiple LVR constraints that are dependent on property type. For BankingProductConstraintV3 is the preferred implementation either: - two separate entries are provided against (for example) constraintType=MAX_LVR, each displaying their own additionalValue with additionalInfo used to contextualise the property type that each applies to, or - a single entry of constraintType=MAX_LVR using the greatest of the two LVR limits as the additionalValue with additionalInfo specifying that there are other additional maximum LVRs based on property type.	New guidance has been published in relation to this query - Multiple LVR constraints not differentiated by rate
31/07/2025	2568	Redirect to app - CX Guidelines When will the data holder CX guidelines for ‘redirect to app’ be published?	We aim to publish CX Guidelines within 3 months of rules and standards changes being made. As Decision 369 was made by the Chair on 30 June, you can expect guidance to be published by the end of September. The CX team will be publicly consulting on the draft guidance via Github on Change Request 700. We welcome your participation in this process and feedback on the draft guidance. You can participate either by commenting on the Github thread or by joining the Maintenance Iteration 24 calls.
03/07/2025	Verbal 1	Filter articles in the support portal Verbal question in the Implementation Call 26/06/2025 Is there a way to filter all articles/artifacts in the support portal that has been changed within a selected period/days so that it can be reviewed in case it is something that needs to be considered, implemented or be made aware of?	There is no option in ZenDesk to be able to filter articles but there is an “Articles changed in last 7 days” page, but the date range is limited to 7 days. A new page has been created to capture the Articles changed in last 31 days as an alternative.
03/07/2025	2544	DP338 - New Fee Types - old version of API called DP338 introduces several new fee types and removes 'Variable'. Can you please advise of the expected behaviour for Get Product Detail and Get Account Detail if one of the new fee types is configured, but the pre DP338 version of these APIs is called. For example: Fee Type is set to Variation Get Product Detail v5 or Get Account Detail v3 is called - which does not have that fee type included	The earlier version should respond with the closest fee type that was available in that version. For example, you may find that a VARIATION fee would have most closely aligned with an EVENT type in the previous version, but it would be up to the Data Holder to determine the most appropriate value. If the fee value is truly variable, but the conditional fields in the fee schema require "One of amount, balanceRate, transactionRate and accruedRate" to be provided, then the most appropriate of those fields with a minimum or typical value could be specified. The additionalInfo field could explain the variable nature of the fee as best as possible.
03/07/2025	2514	Overlapping time of use tariffs We have identified an issue in a data holders CDR energy plan data where overlapping time-of-use periods are being returned for the same tariff, creating ambiguity in determining the applicable rate. For example, A "Night Saver EV Plan" includes an "OFF_PEAK" rate from 12:00 am to 6:00 am and additional overlapping time slots from the general usage network tariff. While the description states that the Night Saver EV rate overrides others during this period, the data holder asks us to rely on the description field where a free text paragraph explains this. We believe that free text descriptions makes it challenging for automated systems to interpret and determine applicable rates. Could the standards provide clarification on whether overlapping time-of-use periods are permitted, and, if so, how automated solutions should interpret and prioritize such overlaps? We seek clarification on how time of use rates are supposed to be structured? We believe they should be non overlapping so that an automated system can select the right time, based on parsing timestamps	The standards currently do not explicitly prevent sharing of overlapping time of use rates. The DH is expected to share rates aligned with how they would have them defined on their plans, which they share with AER as well. In response to a valid consumer data request, CDR Rule 4.6 requires a primary data holder to disclose the requested ‘required consumer data’ it is authorised to disclose in accordance with the standards. Under Schedule 4, clause 3.2 of the CDR Rules, ‘required consumer data’ in the energy sector includes ‘tailored tariff data’ for a relevant account that is open. ‘Tailored tariff data’ is defined by Schedule 4, clause 1.3, item 8 as ‘product specific information in relation to the plan that applies to, and as tailored to, the arrangement to which the account relates’. The Standards also differentiate between basic energy account information and tailored tariff information. The description of Detailed Energy Account Data in the Standards states that Detailed Energy Account Data ‘includes basic energy account information plus tailored tariff information including charges included in the account or plan’. In response to a request for Detailed Energy Account Data, a data holder should therefore share tariff data that it is authorised to disclose which reflects the actual operating tariffs and charges that currently apply to the account.
03/07/2025	2520	Consumer dashboard - data holder The consumer dashboard must contain the details of each authorisation to disclose CDR data specified in CDR Rule 1.15(3), including the period for which the CDR consumer gave the authorisation. For authorisations that expire prior to the scheduled expiry date, are data holders required to display the original period for which the CDR consumer gave the authorisation?	The data holder’s dashboard needs to display the original period for which the CDR consumer gave the authorisation (as required by r 1.15(3)(c)). This is regardless of whether the authorisation expires before or in accordance with the scheduled expiry date. However, there is some flexibility in how a data holder may choose to implement this requirement, as long as the dashboard is simple and straightforward to use (as required by r 1.15(1)(e)).
12/06/2025	2531	We're looking to rely on Product Reference Data to show users potential mortgage options. How reliable and accurate is the data? In the event that providers haven’t updated the information correctly, who is liable for the wrong information?	CDR data quality is a compliance and enforcement priority under the ACCC/OAIC CDR Compliance and Enforcement Policy and the ACCC closely monitors data holder compliance with product reference data obligations to promote good quality data sharing. The ACCC: uses an automated schema validation to monitor conformance with product reference data standards, conducts reviews to compare the information in product reference data to information published on a data holder’s website to assess the accuracy of product reference data, and conducts audits and targeted compliance reviews of CDR participants to ensure they comply with their CDR obligations. The report of our observations from a recent review of product reference data is available here. The Data Standards require data holders to take reasonable steps to ensure that the product data is, having regard to the purpose for which it is held, accurate, up to date and complete. If a data holder fails to comply with its CDR obligations, including in relation to product reference data sharing, the ACCC and, in some circumstances, a person impacted by the breach, may be able to take action against the data holder. Ultimately, data holders are responsible for ensuring they meet their CDR obligations, including those regarding product reference data sharing. Should you start using product reference data, the ACCC welcome feedback about any data quality issues you observe, which you can email to [e-mail] or by making a report via the CDR website. The ACCC considers reports and potential non-compliance in line with the ACCC/OAIC CDR Compliance and Enforcement Policy.
12/06/2025	2523	Clarifications on Account level Features (DP338) Issue #316 brings about changes to the isActivated field on account level features as part of the deliverables for DP338. Having reviewed version 1.34 of the standards we have some queries around the display of features at the account level. Get Account Detail is required to display an array of account features and then present the isActivated field. Q1. There are 30 possible features. For each account sharing request is the expectation that all 30 features are displayed along with the isActivated field? Q2. isActivated now has an option of 'Unknown'. With 'Unknown' the description is as follows - "UNKNOWN or absent if the activation state is unknown". In this instance the isActivated may not be shown, but in that case what is the value in the Feature itself being displayed. This follows on from Q1. If 30 features are shown, but 20 are unknown - where is the value in presenting the information? Q3. In Issue #316 on Jul 20, 2023 ANZ Bank responded to Great Southern Bank regarding the Offset feature on their Home Loan Products. GSB - "Some of our home loan products have offset as a standard feature of the product. Currently, if a customer does not have any linked offset accounts to the home loan, it is deemed as "available for activation" and the isActivated = false. With the proposed change, it is challenging to determine if the status should be true (it is a product standard feature) or false (it is not yet "activated" by the customer)." ANZ - "The proposal deliberately doesn't add to the isActivated property the semantics of whether the feature is defined as part of the product or is selected/activated by the customer. For your home loan customer with a linked offset, isActivated would be true, and without an offset account it would be false. The presence of the feature indicates that the feature is available (i.e., a standard feature of the product) - irrespective of the value of isActivated." Here we have (at the account level) the Offset feature being set to 'Activated' or 'Not Activated' based on if the account has a linked Offset. Yet the standards state the following about the 'isActivated' field: "ACTIVATED if the feature has been activated by the customer or is a standard feature of the product" In the GSB example above, if Offset is a standard feature of the product why is the value of this field not 'ACTIVATED' on the account which does not have an offset account? Our feeling is that the standard features of the product should be shown along with whether they are activated or not on the account. But it is not clear as to whether this is the correct approach.	Q1. The intent of the features array has always been to provide the set of features that are associated with a product or account. If by 'possible' you mean features that can be activated on an account, then yes, they should be included in the array with appropriate values in the respective isActivated fields. If your system includes some features that cannot be associated with a particular account, then they should not be included in the array with that account. Q2. The UNKNOWN option has been provided for cases where you may be unable to determine the status of an available feature for specific reasons (for example, customer acceptance of a third-party loyalty program offered with the product). It does not mean that it is unknown whether the feature is applicable to the account. UNKNOWN will mean to an ADR that the account has the specified features available, but it is unknown whether the consumer is actually making use of them. If you know the actual status, it should be specified as being either ACTIVATED or NOT_ACTIVATED. Q3. As stated in ANZs reply to the GSB query, the presence of the OFFSET feature in the array indicates that an offset is available on the account. The isActivated field then specifies whether the offset has been accepted and in use by the consumer. If the offset account was available but not taken up by the consumer, then NOT_ACTIVATED should be provided. Where the standards state 'or is a standard feature of the product', this may apply for a feature such as DIGITAL_BANKING on an e-savings account, where for example, it could be expected to be ACTIVATED as part of the base features of the account, where it would generally not be possible for it to be deactivated.
15/05/2025	2530	With regard to the new rule that allows ADRs who are also Data Holders to notify a CDR consumer prior to first collection of data, that they will hold the data in accordance with the accredited person's usual data holding practices - I wanted to check if there were any CX guidance published on how this notification should work/look like?	The CX Team has just published draft guidance for Clause 7.2(2A) of Schedule 3 yesterday. You can review and comment on the draft artefacts here: https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/684 (see the latest comment). This includes draft guidance for 7.2(2A)(c)(iv). In regards to your other question: Is the intention of the notification stating that “we’ll handle the data set out in our banking privacy policy” to replace the usual message to refer to the CDR policy? Yes, that is the intention. Again, since this is draft guidance at the moment, we're looking for feedback from the community on these drafts. You can do so on GitHub or if you have additional questions you can also join our next Maintenance Iteration call on May 28. Details of the call can be found on Trumba: https://dsb.trumba.com/Maintenance-Iteration-23/E182538449
15/05/2025	2522	Could you please provide guidance on the reciprocal data holder obligations for non-bank lenders (personal loan products) if we seek to become fully accredited? Will we automatically be considered a "large provider" / data holder and required to comply with reciprocal data holder obligations and if so, from when?	Under the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules), a relevant non-bank lender may be deemed a large provider with data sharing obligations. If a relevant non-bank lender is not already an initial provider, there are two ways in which it may be deemed a large provider: 1. if it meets the thresholds relating to the total value of resident loans/finance leases and customer numbers set out in clause 6.2(3) in Schedule 3 to the CDR Rules, or 2. if it becomes an accredited person (see clause 6.2 in Schedule 3 to the CDR Rules for the meaning of ‘initial provider’ and ‘large provider’). Data sharing obligations for non-bank lenders that are large providers will commence in accordance with the staged implementation tables set out in clause 6.5 of Schedule 3 to the CDR Rules. These obligations are separate from any obligations the large provider has as an accredited person. Large providers will have data sharing obligations in relation to required product data and required consumer data. See clauses 3.1, 3.2 and 1.4 of Schedule 3 to the CDR Rules for the meaning of ‘required product data’, ‘required consumer data’ and ‘covered product’. The ACCC is updating its guidance to reflect the amendments made by the Competition and Consumer (Consumer Data Right) Amendment (2025 Measures No. 1) Rules 2025 and is developing new guidance to assist participants in the non-bank lenders sector to understand their obligations. Other resources which you may find helpful in the meantime to understand how CDR applies to the non-bank lenders sector include: The Explanatory Statement for the Competition and Consumer (Consumer Data Right) Amendment (2025 Measures No. 1) Rules 2025 The Explanatory Statement for the Consumer Data Right (Non-Bank Lenders) Designation 2022.
01/05/2025	2516	While creating a Change Request on Github, I am running into an error, that says "Unable to create request".	We don't provide specific support for GitHub, but you may consider trying to post from a different device or network. Some participants have reported that corporate networks block access to some GitHub features.
17/04/2025	2510	DP#338 and API retirement The DP#338 has multiple changes and one of them is to the “BankingProductFee” schema, where some of the field name has been changed and new fields introduced. We have a PRD tool, where we need to enter the fee details manually. Given the level of changes in the schema, we need to maintain two version of PRD tool for at least 6 months till the API retirement date of 11-May-2026. Can the product API versions (product v3 and product Details v5) be retired earlier, for example, if we are going live on 11-Nov-2025 then can we just support the latest version of product and accounts API?	The Standards require a transition period to support ADRs (and PRD users) in their adoption of new versions, to allow time for any issues to be resolved (while falling back to the previous version). An option may be for you to discuss your concerns with the ACCC. One possibility may be for you to request a shorter transition period, assuming that your implementation would be compliant and adopted successfully by participants by any earlier date. Please note that feedback is now open on Consultation Draft #370 - Amendment of Banking Decision 338 Obligation Date - Draft Standards.
03/04/2025	2505	Will there be definitions for the CDR rules? It is difficult to understand the scope of terms used such as "asset finance", "consumer lease", "business lease" etc. It will be helpful to understand what they encompass?	The terms are not defined, but the ACCC will consider what guidance it can provide when developing new guidance, and updating existing guidance, to reflect the new rules.
03/04/2025	2403	Seeking clarification on the rules for Data Holders when validating redirect URIs. Are ADRs allowed to have dynamic URL query parameters in the redirect_uri? For example, if an ADR has registered the redirect_uri https://www.example.com.au/redirect could they initiate a PAR and set the redirect_uri to https://www.example.com.au/redirect?foo=bar. The interest here is to inject an identifier specific to the consumer authorising the request to allow easier debugging when an authorisation does not complete. The authorisation callback is typically hard to debug especially if the data holder is not encoding the authorization response correctly. Adding an identifier in the query that the data holder must respect when redirecting would make it easier to correlate abandoned authorisations with specific failed authorisation responses.	According to OAuth/OIDC/DCR, the authorisation redirect_uri must exactly match a value in the redirect_uris array submitted during DCR (and also in the sector_identifier_uri file if present). These Maintenance issues may also be relevant to the query: #628 - Addition of a DH-side endpoint for querying the status of a consent establishment flow #649 - Inconsistent JARM error responses
27/03/2025	2507	Metrics calculation during outage Could you please clarify the statement below that is referenced on the CDR metrics and reporting by Data Holders CDS Guide? "No requests received during a planned or unplanned outage are expected to be included in any Get Metrics reporting, but the duration of unplanned outages must be considered in Availability reporting." Do data holders need to exclude all requests received during both planned and unplanned outages from the calculation of performance metrics, invocations, average response time, session count, average TPS, peak TPS, errors, and rejections?	The statement indicates that requests received during an outage are not expected to be reported, because it could be assumed that your systems are unavailable or unstable and not able to accurately receive and record them. It does not state that all requests MUST be excluded, but you may wish to consider whether any metrics that continue to be captured and reported during an outage are providing reliable and valid metrics information. If the reporting of any metrics collected in an outage period is found to significantly skew insight or NFR compliance, the guidance or standards in relation to this may be reviewed.
20/03/2025	2500	Are non-bank lenders that service Reverse Mortgages obligated to join the CDR Framework?	The ACCC cannot provide compliance advice specific to individual scenarios and we encourage you to seek independent professional advice about your compliance obligations. However, we have provided general comments below which may assist. The Competition and Consumer (Consumer Data Right) Amendment (2025 Measures No. 1) Rules 2025 commenced on 4 March 2025. Accordingly, the Competition and Consumer (Consumer Data Right) Rules 2020 (CDR Rules) have been amended to expand CDR to the non-bank lenders sector. Under the rules, a ‘relevant non-bank lender’ that is an ‘initial provider’ or ‘large provider’ must comply with CDR data sharing obligations, with obligations being phased in from 13 July 2026. The meaning of initial and large providers is set out at rule 6.2 of Schedule 3 to the CDR Rules. Relevantly, clause 6.2(2), states that a relevant non-bank lender is considered a ‘large provider’ if on 4 March 2025 or on any later 1 July:   it is not an ‘initial provider’ it has over 1,000 customers on that day, and the total value of the lender’s resident loans and resident finance leases reported to the Australian Prudential Regulation Authority (APRA) under the applicable standards (by the lender and each of its associated non-bank lenders): is over $1 billion in relation to the most recent calendar month for which a report was given to APRA, and averaged over $1 billion during the previous 12 months. A relevant non-bank lender is also considered a large provider if it is an ‘accredited person’ on or after 4 March 2025. Data sharing obligations for large providers will commence from 13 July 2026, in accordance with the staged implementation table set out in clause 6.5 of Schedule 3 to the CDR Rules. Non-bank lenders that meet the requirements of an ‘initial provider’ as stated in clause 6.2(1) of Schedule 3 will also have data sharing obligations from 13 July 2026 (see clause 6.4 of Schedule 3). Note, data sharing obligations do not apply to product and consumer data in relation to certain products, including reverse mortgages. That is, data holders may (but are not required to) disclose relevant data in relation to reverse mortgages (see clauses 3.1(2) and 3.2(3) of Schedule 3). Other resources which you may find helpful to understand how CDR applies to the non-bank lending sector include: the Explanatory Statement for the Competition and Consumer (Consumer Data Right) Amendment (2025 Measures No. 1) Rules 2025 the Explanatory Statement for the Consumer Data Right (Non-Bank Lenders) Designation 2022.
20/03/2025	2491	We are receiving multiple 504 Gateway timeout from this endpoint GET https://api.cdr.gov.au/cdr-register/v1/banking/data-recipients/brands/software-products/status, can this please be looked in to	The CDR TechOps are aware of this issue and is actively working with our vendor on it. We had observed that the vendor had worked to reduce the overall intermittent gateway timeout percentage so the frequency of occurrence experienced by Wise should be reduced by now.
13/03/2025	2485	Are there are any further details around demand charge standards, particularly regarding the definition of units and time periods? In particular if there are any more detailed definitions for fields like "chargePeriod" and "measurementPeriod" that can be found in the relevant schemas. Are there information distinguishing between instances of cents vs. dollars in general?	1. "chargePeriod" and "measruementPeriod" are both ENUMs, i.e. Enumerated values. That means they can only have a value from a set list. The list of values they can have is defined in the schema and can also be viewed on the standards page. 2. The "cents" vs "dollar" was a known issue which should have been fixed in recent release of the APIs by Australian Energy Regulator (who are the data holder and host of the energy public CDR APIs). They should all be in $$.cc format (i.e. dollar and cents). If you notice any discrepancies that it is a data quality issue which would need to be fixed by AER. For questions about how the data is to be interpreted or understood, the best point of contact would be the Australian Energy Regulator who are the data holder (and provider) for these API. Their CDR page also has their contact information
06/03/2025	2501	Get Metrics data refresh Is there a confirmed period of time that data needs to be refreshed for Get Metrics data, a higher frequency add cost burden. What would be the maximum that would be allowed (i.e. 24 hours)?	There is no latency requirement specified for the Get Metrics data. You could consider though that it provides a range of metrics from hourly to monthly, so being as low as 5 minutes may not be necessary. Some existing guidance on this topic may be found here - What is acceptable data latency for providing metrics? - Metrics reporting current day - Frequency of Calls to Get Metrics
06/03/2025	2498	Get Transaction Detail V2 Implement the Get Transaction Detail V2 in March to enable clients to share their NPP data at earliest with the ADR’s. In this regard for a particular scenario we would like to validate our approach. Scenario: As a data holder, we will need to support both versions of the Get Transaction Detail API until at least 14th July 25 and possibly after that date until V1 is deprecated. The Get Transaction detail is called based on “Is Detail Available” data item when true. Up until now we were extracting NPP data only for X2P1.01 service as required now with extended services in V2 the data retrieved will be for all NPP services, so all services associated with the NPP will return “Is Detail Available” = TRUE. This results in a scenario where ADR can call either V1 or V2 version of the Get Transaction Detail API. If ADR calls with Get Transaction Detail V1 for a service other than X2P1.01 then it becomes challenging to respond to the ADR as: - The transaction data exists but cannot be accurately represented using the Version 1 payload structure. - The service type does not align with the Version 1 API, which exclusively supports "X2P1.01" services. To manage the response our approach would be to throw a 406 Not Acceptable error, accompanied by the following error message { "errors": [ { "code": "UnsupportedVersion", "title": "Unsupported Version", "detail": "The requested transaction details are not available in API Version 1. Please use Version 2 for non-X2P1.01 services." } ] } Q1. Can you please confirm if the proposed approach is a viable option? Q2. If the above approach is not viable, how should data holders manage the transition period where both API versions are supported, particularly when dealing with transactions that can only be fully represented in the newer version (V2)?	Answered on this issue thread 664
06/03/2025	2497	Get Customer Detail API response schema Seeking clarification regarding the Get Customer Detail API response schema, specifically the behaviour of the customerUType field. Based on the documentation (Customer Detail v2 Schema), the assumption is that the response will include either the person or organisation object, depending on the value of customerUType, but never both simultaneously. Can you confirm if this assumption is correct? Or is there any scenario where both person and organisation objects could appear in the same response?	Only one object is expected to be specified, depending on the consumer type. More details related to this query are available in this guidance - Get Customer response for sole trader - Sole trader Get Customer API ResponseCommonCustomer response
06/03/2025	2494	Infosec endpoints that should be captured under HighPriority invocation metrics In CDS Specification under performance requirements, it is stated that infosec endpoints should be captured in the HighPriority tier. Is there a place I can find the list of endpoints that falls under infosec endpoints? Endpoints seems outdated. Are all endpoints mentioned under Security Endpoints considered as InfoSec endpoints?	Yes, "InfoSec endpoints" generally refers to the endpoints described in the Security Endpoints section. If you believe there are specific endpoints in your solution that should be included or excluded, I'd be interested in hearing any feedback or suggestions that may improve service insight for the Regulator. I'm not sure where you found the [2] link, but it refers to a deprecated version of the Standards
06/03/2025	2492	ADR Using a + delimiter to separate scopes in an auth request An ADR is using + in the auth requests to separate scopes The OAuth 2.0 standard (RFC 6749) and OpenID Connect require space-separated scopes, meaning scope values should be separated by spaces (%20), not +. https://datatracker.ietf.org/doc/html/rfc6749 Section 3.3 does specifically say space delimited or the authorisation request, which also refers to section 3.3. An example of would be &scope=openid+common%3Acustomer.detail%3Aread +common%3Acustomer.basic%3Aread Is it acceptable to use the + delimiter to separate scopes rather than %20? Our server does not accept + and hence would like some guidance on the requirement to support + or not	'scope' is an optional parameter at the authorize endpoint, but the value in the PAR would be expected to override it. A '+' is a form-encoded space as noted in https://www.rfc-editor.org/rfc/rfc6749#appendix-B, so I think that behaviour could be aligned to the spec.
27/02/2025	2395	User Experience when creating a new authorisation In instances where the user is finalizing the authorization process and selects the confirm button, the data holder is responsible for transmitting the response to the ADR through the redirect URL. Should an unexpected complication arise causing the application to freeze during this redirection, the new consent record is retained by the data holder but remains inaccessible to the ADR. What is the optimal user experience for such scenarios? "New consent" is referring to the process of saving the arrangement in the data holder's system following the user's confirmation action in the new authorization setup.	The below focuses on UX guidance to help address the scenario. We will share more details on when ADRs and DHs are expected to provide consumer dashboards following further discussion with CDR agencies. DH dashboard If the DH detects an issue with the authorisation, such as where the DH knows or suspects the ADR cannot collect data, the DH may notify the consumer of the suspected error and direct them to contact the ADR for more information. This is not a requirement but a best practice recommendation. Alternatively, a DH may choose to display a default message on the consumer dashboard indicating that no data has been shared yet. This is also optional, and would be superseded by the rule 7.9(1) requirement once data has been disclosed. Once data has been disclosed, the authorisation must include the information required by rule 7.9(1) relating to Privacy Safeguard 10 (for a visual example see 5CM1.00.07 in CX Guidelines for data holder dashboards, authorisations: default example). ADR dashboard ADRs could adopt a similar approach for this scenario where a consent is active but data has not or cannot be accessed, which would be superseded by the respective ADR rule 7.4 requirement when/if access commences. If an ADR detects a data access issue, they may wish to notify the consumer of the suspected error, request a new consent, and may provide details with which to advise the consumer to withdraw the faulty authorisation via the DH dashboard.
06/02/2025	2444	OpenAPI Specification as a requirement in the standards CDR APIs often have OpenAPI specification (OAS) files, and the principles for consumer data standards point to the use of open standards wherever possible and to ensure high level developer experience, but is there any requirement in the standards that APIs MUST or SHOULD include an API description in an OpenAPI Specification file format?	There is not currently a statement in the Standards that says APIs must/should include an OAS, as they focus primarily on the technical aspects of sharing, rather than copyright or further usage. For more details about the CDR, including Rules for certain participant types, you may also want to refer to - https://www.cdr.gov.au/for-providers - https://www.cdr.gov.au/for-providers/become-accredited-data-recipient
30/01/2025	2441	Dataholder Dashboard - "Amend" label requirement When displaying Authorisation History details, is it required to show the "Amended" label over the sections that have changed? Is it not adequate to show the snapshot of each amendment with all the details?	The DSB is unable to provide advice on individual implementations of the CDR rules. However, we note the following general guidance: Rules 1.15(1)(b), (5)(a) and (3)(h) require the consumer dashboard to contain details of each amendment (if any) that has been made to an authorisation. The DSB's published Amended authorisation wireframes contain an example of how these rules can be satisfied (Consent Management (Data holder): Authorisations, Amended Authorisations). However, please note this is an example only. It is for data holders to determine how they comply with the rules, by for example: - only including the summary text under the date on the ‘Authorisation history summary’ screen without any ‘amended’ labels on the screens under the ‘Authorisation history details’ tab - only including the ‘amended’ labels in the screens under the ‘Authorisation history details’ tab without any summary text on the ‘Authorisation history summary’ screen. As suggested by the CX Guidelines, the DSB considers it best practice for DHs to implement both options (1) and (2) (i.e. to provide both the summary text and the ‘amended’ labels), as there may be times when it is insufficient to only implement one. We note that DHs are also not limited to only using these two options. However, simply displaying past versions of an authorisation e.g. under the ‘Authorisation history details’ tab without flagging the details of what has been amended is likely not compliant.
30/01/2025	2481	A query regarding the most appropriate logic to ‘unattended’ API calls. ‘x-fapi-customer-ip-address’ is specified as 'optional' parameter for the banking API calls by ADR. Should a data holder just rely on this field to determine if the call was 'unattended', or if we also need to look at 'x-cds-client-headers' ? The specifications states that "x-fapi-customer-ip-address" should be populated with a valid IP address for customer present calls. It does not specifically say whether this header can be present for "unattended" calls as well. There is a possibility that this header is present for "unattended" calls as well, for example, with invalid IP address value such as 0.0.0.0?	The x-fapi-customer-ip-address header is optional because it is not expected to be present when unattended calls are being made. It should only be populated when the customer is present, as the description states: “The customer's original IP address if the customer is currently logged in to the Data Recipient Software Product. The presence of this header indicates that the API is being called in a customer present context.” In terms of Data Holder logic, the Definitions section states: * Customer Present: Authenticated API requests made in direct response to interactions by the end customer using the digital services of the Data Recipient Software Product will be considered "Customer Present". Technically a data holder will define an API request as "Customer Present" if, and only if, the x-fapi-customer-ip-address header is populated with a valid IP address of the end customer's device. * Customer Not Present: Authenticated API requests that are not deemed to be "Customer Present". * Unattended: A synonym of "Customer Not Present". 1. You should probably not only check for the presence of the x-fapi-customer-ip-address header, as the definition states it must contain a valid IP address. 2. There should not be a need to also check for the x-cds-client-headers header as that is not part of the current requirement. 3. It would be helpful if you have any insight as to inconsistencies you have observed in requests, such as invalid IP addresses being provided, or an invalid or missing IP header when the CDS Client header appears to indicate that the consumer is present.
23/01/2025	2473	The option 2 change to the "Get Transaction Detail" in the "new Enums for voluntary disclosure of additional service overlays" #664 proposes the following NPP payment service types. X2P1 BSCT CATSCT IFTI It is our understanding that IFTI payments are not an NPP Payment service type. BRDR is the domestic NPP payment of an IFTI payment (being the actual International Funds Transfer which is a SWIFT payment). Could you confirm whether you are expecting data holders to translate BRDR NPP payments to be represented in CDR Get transaction details as an IFTI nppPayload service type? What is the expectation on the mapping of BRDR to IFTI? Are the additional enums considered voluntary? Do we have the option of not including IFTI?	An excerpt from a statement in the change request: "An NPP payment may be used as the final leg of an 'inward' IFTI - that is, a payment originating overseas, sent through an NPP participant as an intermediary on the way to another NPP participant as the final destination." As far as we're aware, IFTI is the code recognised/provided by AP+ for international instructions. If your systems or provider/vendor use BRDR as a kind of subset of the IFTI type, then the transactions should still be provided as IFTI. The payment service details are mandatory, even if they require a level of mapping to conform to the standards, similar to most other mandatory fields.
16/01/2025	2474 Part 1	We would like to seek clarification regarding the upcoming transaction security update related to cipher suites, as per the requirements mentioned: Until March 17th, 2025: Only the following cipher suites SHALL be permitted: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 The following cipher suites SHOULD NOT be supported: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 From March 17th, 2025: Only cipher suites recommended in [BCP195] SHALL be permitted. Just so you know, please go through the link:https://consumerdatastandardsaustralia.github.io/standards/index.html#transaction-security. Query: 1. Can the changes required for compliance with section 8.5 of [FAPI-1.0-Advanced], BCP195 be applied before March 17th, 2025 (e.g., by March 16th, 2025)? We want to ensure timely compliance with the requirements and avoid any potential ambiguity. 2. Please confirm whether the Cipher suites that should not be supported Until March 17th, 2025 are expected to be removed from the current solution.	1. Yes, as long as you are still meeting the requirements of the statement - Until March 17th, 2025: Only the following cipher suites SHALL be permitted: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 The following cipher suites SHOULD NOT be supported: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 2. If you are suggesting introducing some stronger ciphers that are part of BCP 195 before the obligation date, we may be able to consider a change to the Standards to support that. Another option for you may be to only include ciphers that are common to the current requirement and the future requirement and only introduce any additional stronger ciphers from BCP 195 after the obligation date.
16/01/2025	2474 Part 2	We need some more detailed insights to get a clear understanding of the changes please find them below. Effective Date for Cipher Changes: It is mentioned that the current ciphers must remain in use as below until March 17, 2025, Until March 17th, 2025: Only the following cipher suites SHALL be permitted: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 The following cipher suites SHOULD NOT be supported: TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 Could you confirm below, 1. If there is a specific date and time for the pre-March 17 requirement mentioned here, if data holder have all of the above ciphers enabled in the system, should we remove immediately? please let us know how soon this has to be achieved since this has to be done through a release iteration. 2. Will it be considered as non compliance if we keep TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 & TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 ciphers till March 17th? 3.Is post-March 17 requirement transition expected to be in production on 17th March or should it be after 17th March? Technical Rationale for Changes Post-March 17: Could you elaborate on the technical reasoning behind the requirement to introduce new ciphers only after March 17?	Re: 1. If there is a specific date and time for the pre-March 17 requirement mentioned here, if data holder have all of the above ciphers enabled in the system, should we remove immediately? please let us know how soon this has to be achieved since this has to be done through a release iteration. Please refer to the Standards - Interpretation Note that, in these standards, the key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL are to be interpreted as described in [RFC2119]. Re: 2. Will it be considered as non compliance if we keep TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 & TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 ciphers till March 17th? I cannot comment on compliance, please refer to ACCC guidance - Compliance requirements for data holders Re: 3. Is post-March 17 requirement transition expected to be in production on 17th March or should it be after 17th March? The Standards state: From March 17th 2025, the following requirements SHALL apply: In addition to section 8.5 of [FAPI-1.0-Advanced] only cipher suites recommended in [BCP195] SHALL be permitted. This means the change applies on the 17th and onward. Re: Could you elaborate on the technical reasoning behind the requirement to introduce new ciphers only after March 17? Most changes to the Standards are made with as Future-Dated Obligations. This allows all participants to adopt and be ready for changes to occur. March 17, 2025 is one of the pre-determined Obligation Dates for changes to be aligned with. For details, refer to - https://consumerdatastandardsaustralia.github.io/standards/includes/endpoint-version-schedule/#obligation-date-schedule