Consultation Draft 376 - White label brand arrangements - Draft Standards

[Technical-DSB]

Decision made

Decision 376 was made by the Data Standards Chair on 28 November 2025. The Explanatory Document and Decision are available here.

The changes will be incorporated into a new release of the CDR data standards.

2 October 2025: Consultation Draft published

Overview

Feedback is open for Consultation Draft 376.

This consultation proposes draft standards to accommodate data holders with white label brand arrangements as they relate to the consumer data provider list and product reference data. The accompanying Explanatory Document provides the background and context for these draft standards, and an assessment of potential impacts.

Community views are being sought on the draft standards and positions outlined in this consultation draft. Feedback received will be considered before any binding standards are made by the Chair.

Consultation Documents
The Explanatory Document and Consultation Draft 376 can be found below:

• CD376 - White label brand arrangements - Explanatory Document.pdf
• CD376 - White label brand arrangements - Draft Standards.pdf

Feedback
Feedback on this consultation draft will inform the binding standards to be considered by the Data Standards Chair.

You can submit responses to this consultation up until the close of Friday 31st October 2025. Feedback may be provided on #376. You may also provide feedback in writing directed to contact@dsb.gov.au. Stakeholders are also encouraged to raise queries on this GitHub page, which may help inform the development of feedback.

Feedback posted on GitHub is public by nature at the time of submission. Content posted on GitHub should be made according to the community engagement rules published by the DSB.

---

Edit - 28 11 2025: Decision document published
Edit - 02 10 2025: Consultation Draft published

[Technical-DSB]

Feedback is open for Consultation Draft 376.

This consultation proposes draft standards to accommodate data holders with white label brand arrangements as they relate to the consumer data provider list and product reference data. The accompanying Explanatory Document provides the background and context for these draft standards, and an assessment of potential impacts.

You can submit responses to this consultation up until the close of Friday 31st October 2025. Feedback may be provided on #376. You may also provide feedback in writing directed to contact@dsb.gov.au.

The consultation documents can be found in the original post.

[Technical-DSB]

The attached submission was received via email and is being shared with permission.

• Feedback_Draft376_RicRichardson.pdf

[biza-io]

Biza.io is supportive of the intent of Draft 376 and provides the following feedback.

Support for brandGroup Field

We support the introduction of the brandGroup field to enable grouping of multiple funders under a single consumer-facing brand. This aligns with real-world white-label models and simplifies presentation without losing underlying granularity. While perhaps not "perfect" in all ways this represents a relatively small change in the context of the need for timely implementation certainty. The field should remain optional and well-documented to ensure consistent implementation.

Versioning & Implementation Timing

We prefer that the new fields (brandGroup, productBaseUri) be incorporated into existing upcoming versions (e.g. v5/v7) rather than new branches.

Biza intends to activate 50+ brands prior to the proposed FDO, including some which have relevant Brand Groups, and has applied commercial discounts for customers to achieve early activation dates (ie. early adopter discounts are contingent on prescribed go live dates being met). As such certainty on the specification in this calendar year (2025), and readiness of the Regulator given the ample notice they have already been provided*, is critical to avoid unnecessary rework and costs to mandated parties.

*Biza first raised this issue with the Regulator in February 2025 and again in June 2025

Support for Splitting productBaseUri from publicBaseUri

We support separating productBaseUri from publicBaseUri as a simplification first proposed by Biza and others as far back as 2022. This distinction improves clarity between PRD endpoints and the operational status APIs and should be implemented alongside brandGroup on the same timeline.

[ACCC-CDR]

The Australian Competition and Consumer Commission (ACCC) welcomes the opportunity to comment on proposed standards to accommodate data holders with white label brand arrangements. Complex white label arrangements exist in the non-bank lenders sector, and the ACCC supports changes to the standards to enable consumers and participants to interact with CDR in a streamlined way. The proposed draft standards are consistent with the Register API changes required to facilitate options 1B and 2B.

Consumer experience

The ACCC supports Option 1B to implement changes to support brand grouping. Including additional metadata during register onboarding would streamline the ability for a data holder to indicate that different brands on the CDR Register are associated with the same brand-owner. This change would improve consumer experience during CDR consent flows, including by avoiding the need for long “Select provider” lists and minimising the risk of incorrect selection and poor consumer outcomes.

The ACCC would support Option 1B by providing guidance and targeted support to assist data holders with the correct usage of the proposed ‘Brand group’ field along with the existing ‘Brand name’ field.

To facilitate this change, the ACCC would need to implement system changes to the Register API endpoints defined in the Standards, along with changes to the Register and Accreditation Application Platform (RAAP) Participant Portal. These changes could be scheduled for implementation prior to commencement of CDR obligations in the NBL sector on 13 July 2026, subject to timely publication of the Standards.

PRD endpoints and obligations

To accommodate complexities associated with sharing PRD in complex white label arrangements, where PRD may be offered by more than one entity, or be in different locations, the ACCC supports Option 2B to implement changes to split the publicBaseUri field. This would provide more flexibility for data holder brands to separately configure the public and product endpoints in the RAAP Participant Portal.

System changes required by the ACCC could be scheduled for implementation in tandem with the system changes required for brand grouping under Option 1B, subject to timely publication of the Standards.

Other consultation questions

Should the Register APIs provide the ability to surface additional metadata provided by data holders for ADRs, such as common keywords or acronyms that may help consumers find their brand in the provider list via search keywords or other methods? How, or why not?

We consider there is value in exploring the long-term value of a tagging system which could allow participants to add metadata to support positive consumer outcomes. However, this approach could introduce new risks which would need to be appropriately managed or mitigated.

In the Certificate Signing Request Profile section, the Organization (O) field for Server certificates indicates it is a Mandatory field to contain a ‘Brand Name’. This suggests that a certificate is required per ‘brand’. Would there be value in indicating that one certificate could be shared by multiple brands? If so, what changes do you think are required to allow this?

Sharing certificates would potentially realise significant reductions in cost and operational effort for a variety of ecosystem participants, but this needs to be balanced against any potential risks. These risks include misuse of certificates which could affect multiple brands simultaneously, increasing the likelihood of fraud and undermining consumer trust. Additionally, the administrative burden of managing individual certificates across multiple brands could lead to inconsistent practices and compliance challenges, particularly for smaller participants. These risks could be mitigated through approaches such as establishing a business governance framework.

We note the following impacts:

• it may be desirable to enhance the RAAP Participant Portal to reflect the certificate sharing, although it seems that this may not be absolutely required for holders to implement the sharing.

• it would be necessary to relax the current rules in the Standards around the content of the Organisation field (currently the brand name must be used).

• Guidance could be developed around the use of Fully qualified Domain Names, Subject Alternative Names and Common Names.

• CDR Register’s authorisation server would require changes to ensure it supports multiple register entities.

[MastercardOpenFinanceAustralia]

Mastercard welcomes the opportunity to comment on the proposed standards and provides the following feedback:

The proposed changes to white label brand arrangements are a positive step forward. We recognise the challenges that white labelling presents for both the user experience and maintaining data consistency. In response to Challenge 1 outlined in the Explanatory Document, we support Option 1B. Grouping providers by brand will enhance the consumer experience by making it easier for individuals to identify their provider and navigate the authentication process successfully.

In response to the disadvantages outlined in the Explanatory Document, we acknowledge that implementing brand grouping represents a relatively minor development effort for data holders and contributes to greater data consistency across the ecosystem. We believe it is in the competitive interest of all participants to prioritise an optimal user experience. However, we do not support mandating brand grouping through Consumer Experience (CX) standards. Instead, we recommend that the Data Standards Body (DSB) publish non-binding guidance that outlines the importance of data consistency across all brands. This guidance should clearly express a preference for using trading names over legal names to support consumer recognition and usability.

[Technical-DSB]

Sharing the attached submission on behalf of AFIA. The submission was received prior to the end of the consultation period.

• 20251031 AFIA sub to DSB consultation draft 376 white labelling.pdf

[perlboy]

Sharing certificates would potentially realise significant reductions in cost and operational effort for a variety of ecosystem participants, but this needs to be balanced against any potential risks. These risks include misuse of certificates which could affect multiple brands simultaneously, increasing the likelihood of fraud and undermining consumer trust. Additionally, the administrative burden of managing individual certificates across multiple brands could lead to inconsistent practices and compliance challenges, particularly for smaller participants. These risks could be mitigated through approaches such as establishing a business governance framework.

The ability to share a single backend MTLS certificate for a single NBL but many brands represents a significant administrative efficiency gain reducing, in some cases, 100s of certificates versus 1. Arguments related to consumer trust and fraud are misplaced because the Consumer never sees any certificate details issued by the Register (it's a certificate for MTLS not a browser presentation). It's also a weak counter from a security perspective because:

1. Certificates issued by the Register are still validated as being issued by the Register in both directions (i.e. Private CA + MTLS)
2. Certificates would still have a list of SANS for which FQDNs are considered valid, and this is controlled by the Register at issuance
3. The FAPI profile over the top of the transport layer security binds to a specific issuer and this is path based. That is to say regardless of the sharing of a single hostname the Standards already state "Where a Data Holder has multiple brands, each brand MUST have a separate issuer." and so the security domains are separated per brand at a path level.

From a Standards perspective would agree with the Regulator that the certificate profile will need adjustment for Organisation attribute being set to "Brand Name". Suggest the wording of this can be changed to "Brand Name or Funding Entity Name" where Funding Entity Name represents the legal entity of the funding entity. As this certificate is not visible to the Consumer this represents an ideal mechanism for Recipients encountering common problems to be able to clearly delineate whether it is a brand specific or a funding entity specific platform issue.