Brands in the CDR ecosystem

• Introduction
  • Purpose
  • Entity Model
• Clarification on the term 'data holder' 
• Data holder brands
  • Data holder brands discovery
  • Registering with data holder brands
  • Listing brands in the consent flow
  • Display of brands on the public register
• Information stored against a data holder brand
  • Technical Endpoints
  • Certificates
  • On-boarding
• Usage of data holder brands
  • Open ID Provider Configuration Endpoint
  • Dynamic Client Registration
  • Product Reference Data
  • Outages and Statuses
  • Metrics Collection
  • Consumer Data
• Brand Configuration Use Cases
  • Secondary Brands
  • Different Products / Platforms
  • Multiple Sectors
  • White Labels
• Conclusion
• References

This is a live document and will be updated as use cases for brands are identified and evolve in the Consumer Data Right (CDR) ecosystem. It was updated on 4 March 2026 to account for changes to the CDR system. These changes include DSB decision 376, which adds a brandGroup field for data holder brands.

Introduction

The CDR Register (hereinafter “the Register”) stores key information about data holders and data recipients , and is critical to conveying trust to participants within the ecosystem. The Register is key to how participants discover each other, allowing them to confidently exchange data and detect changes in the range and status of participants as they evolve over time.

Different business models and relationships between entities exist in the CDR, and it is important to appropriately reflect them on the Register. These relationships are often complex and flexibility is needed to cater for both current business models and future business models. As new business models become part of the Consumer Data Right, these models are tested against the Register design and required improvements to the design are identified through our collaborative design process.

We encourage participants to reach out and raise questions about how future changes in their business models may be catered for by the Register.

 Purpose

The purpose of this article is to provide technical commentary into how participants can segregate their organisational model into various brands for CDR purposes, and how these models are configured within the Register.

 Entity Model

Data holders and data recipients are represented as legal entities and brands within the Register. Legal Entities represent the company information, synonymous to how entities are conveyed on the Australian Business Register.

Both data holders and data recipients are expected to have one or more brands within the Register. These brands are used to help segregate the different functions of the participant.

The ecosystem entities section of the Register design details these entities and this entity relationship diagram conveys the structure of these relationships.

Participant Entity Relationships

Data holders MAY use brands to:

1. Differentiate between product domains within the organisation. These products may be within the same sector (for example business vs retail), or cross sector (banking vs energy)
2. Differentiate between different software platforms and identity stacks within the organisation
3. Differentiate between different consumer facing business brands within the organisation
4. Capture non-designated white label brands the legal entity is responsible for

Data recipients MAY use brands to:

1. Differentiate between different business brands within the organisation
2. Differentiate between different software platforms and collections of software products within the organisation

This list is by no means complete and the application of brands within the Consumer Data Right is assumed to evolve over time. New and differing applications of brands are expected to be identified as new types of participants enter the ecosystem and new sectors are adopted.

Clarification on the term 'data holder' 

For the purposes of the CDR Rules and Register, ‘data holder’ is defined in section 56AJ of the Competition and Consumer Act 2010 (the CCA). The CCA specifies three ways an entity can be a data holder of CDR data. The first is the entity is specified in a sectoral designation instrument, the second is if an entity is accredited and was disclosed CDR data other than through the CDR, and the third is if the conditions in the CDR Rules are met. Authorised deposit-taking institutions are data holders in the banking sector, and ‘relevant non-bank lenders’ are data holders in the non-bank lenders sector.[1]

Data holder brands in the Register are a separate concept that is not defined under the CCA. Data holder brands are used to represent brands under which products are marketed by the legal entity and readily recognised by consumers.

The Consumer Data Standards (CDS) describes “data holder” in the section on CDR Federation. The CDS is not concerned with the legal entity, therefore “data holder” in the context of the standards relates to the data holder brand in the Register. Brand filtering on product reference data endpoints represents market segmentation such as retail and business for a data holder brand, not different brands associated to a single legal entity.

Data holder brands

Data holders have much to consider when identifying what brands are relevant to their organisation. This requires consideration of the different functions that brands facilitate within the ecosystem.

Data recipients are responsible for discovering data holder brands within the ecosystem, ensuring they are appropriately registered with each brand, and exposing this list of brands to the consumer as part of the consent flow. 

Data holder brands discovery

The Register exposes the Get Data Holder Brands API to enable accredited data recipients to discover the data holder brands active for consumer data sharing within the ecosystem. This is an authenticated API dedicated for this purpose. 

The Register also exposes the Get Data Holder Brands Summary API to enable discovery of brands related to product reference data (PRD). This API is not authenticated.

Registering with data holder brands

Prior to exposing a data holder brand to the consumer, accredited data recipients (ADR) are required to register with each brand, using the Dynamic Client Registration process, as defined in the Register design. This ensures the data holder brand provides the ADR with a client ID required to request consumer data.

Listing brands in the consent flow

Accredited data recipients can guide a consumer to request consumer data from any data holder brand they have registered with. The CX guidelines outline how a data recipient’s software product may display the list of data holder brands to the consumer during the consent flow.

CX Guide on  provider selection

 Display of brands on the public register

The Consumer Data Right public register is published at: https://www.cdr.gov.au/find-a-provider.

The public register displays CDR participant legal entities, their associated brands (and software products where relevant) and their statuses for the general public to reference.

The brands for each legal entity are displayed as follows:

Public Register displaying a legal entity and the associated brands

Information stored against a data holder brand

The Register stores technical details against the data holder brand.

Both technical endpoints and certificates are required to enable participants to facilitate the implementation of the Consumer Data Standards.

 Technical Endpoints

Data holders are required to register base URIs against each of their brands. This information is exposed to accredited data recipients via the Get Data Holder Brands API.

Please refer to the “Participant Endpoints” subsection of the Security Endpoints section for further details.

A subset of this data is publicly available via the Get Data Holder Brands Summary endpoint, e.g. for use cases concerning product reference data.

Certificates

Server certificates are issued at a brand level to data holders. SAN certificates used to protect endpoints spanning multiple domains can also be issued by request and reference to this information is stored in the Register.

Please refer to the Certificate Management section for further details.

On-boarding

The on-boarding process details how participants enter their technical endpoints and the issuance of certificates on the Register for the purpose of consumer data sharing.

Please refer to the On-boarding Guide for further details.

 Usage of Data Holder Brands

Data holders have obligations for each of their brands to conform to the Consumer Data Standards.

 Open ID Provider Configuration Endpoint

The InfoSecBaseUri value is used to discover the data holder Open ID Provider Configuration Endpoint as described in the “Participant Endpoints” subsection of the Security Endpoints.. A unique endpoint per brand allows for unique issuer values per brand.

Dynamic Client Registration

The Open ID provider configuration endpoint publishes the data holder brand’s registration endpoint. There is a one-to-one relationship between a brand and a client registration from a software product, therefore the data holder brand issued client id is unique between brands.

Please refer to Client Registration – CDR Data Standards.

Product Reference Data

The ProductBaseUri provides reference to the endpoints used to host product reference data (PRD).

The product reference data brand feature in the Get Products API is intended only for sub-brands of a master brand and should not be overloaded with products belonging to any other brand hosted on the Register.

Please refer to the Get Products and Get Product Detail APIs in the Consumer Data Standards.

Outages and Statuses

The PublicBaseUri provides reference to the endpoints used to host the outage and status information. Brands must report this information separately from other brands.

Please refer to the Get Status and Get Outages APIs in the Consumer Data Standards.

Metrics Collection

The AdminBaseUri provides reference to the endpoint used to host the Get Metrics information. Brands must report this information separately from other brands.

Please refer to the Get Metrics API in the Consumer Data Standards.

Consumer Data

The ResourceBaseUri provides reference to the resource endpoints used to host consumer data.

Please refer to the Resource URI section in the Consumer Data Standards.

Brand Configuration Use Cases

Brands are used to help data holders and data recipients segment their organisation and platforms in logical ways. There are many considerations to be made when determining which use case to align to.

The following outlines the currently supported use cases when creating brands on the Register:

Secondary Brands

Data holders and data recipients may have subsidiary business brands which the consumer differentiates when interacting with current offerings.

Given that consumers already see these brands as different entities, it is logical to segregate these brands into different entries on the Register.

This results in the following:

1. Consumers will see these data holder brands as different entries during the consent flow; and
2. Consumers will see these brands as different entries in the public register

Different Products / Platforms

Data holders and data recipients may have different platforms running the systems which expose these products to the consumer. This would be typical for such arrangements as business and personal banking if they represent different identities and endpoints exposed to applications and the consumer.

Therefore, it would be logical to breakup these products/platforms into different brands if:

1. Each platform is independently identifiable to the consumer (e.g. Demo Bank – Personal vs Demo Bank – Business); and
2. Each platform is hosted with different technical endpoints

Multiple Sectors

An extension from Different Products / Platforms, differing sectors which are hosted on different platforms would be segregated by brand.

It may be preferable for data holders or recipients who have a unified, sector agnostic platform to configure this model as a single brand on the Register.

White Labels

White labelling brings a whole new set of scenarios to cater for in the Consumer Data Right. Technical commentary on these scenarios has been authored in the article White Label Brands in the CDR. For guidance on how to comply with the CDR rules for white labelled products, see:

• section 5.7 and 6.5 of the ACCC’s Compliance guide for data holders in the banking and non-bank lenders sectors
• section 5.1.2 of the ACCC’s Compliance guide for data holders - energy sector.

Conclusion

The usage of brands within the Consumer Data Right ecosystem provides flexibility on how future models may be conveyed on the Register. As the use cases evolve over time, the application of brands may be extended to accommodate these use cases.

We encourage participants to engage in the collaborative design process so these business models can be identified and considered in the Register design.

References

CDR Register Design	https://consumerdatastandardsaustralia.github.io/register/#introduction
CX Guidelines	Consumer Experience (CX) Guidelines
Consumer Data Standards	https://consumerdatastandardsaustralia.github.io/standards
Consumer Data Right Public Register	https://www.cdr.gov.au/find-a-provider
CDR On-boarding Guide	https://www.accc.gov.au/focus-areas/consumer-data-right-cdr-0/on-boarding-guide
Noting Paper 169	https://github.com/ConsumerDataStandardsAustralia/standards/issues/169

---

[1] For more information on whether a person is a data holder in the banking or non-bank lending sector, see section 2.2 of the ACCC’s Compliance guide for data holders in the banking and non-bank lenders sectors.