Introduction
The CDR Register is responsible for storing data holder and data recipient records, required to convey trust to participants within the ecosystem. These relationships are key to how participants discover each other, exchange data and detect changes of participants as they evolve over time.
These relationships are key to convey the different business models that will occur in the ecosystem. However these relationships are often complex but require sufficient flexibility to cater for current known business models and are sufficiently adaptable to cater for future business models. Therefore, as new business models become part of the Consumer Data Right, it is expected these models will be tested against the Register design and required improvements to the design 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 CDR Register.
Purpose
The purpose of this guide is to provide technical commentary into how participants can segregate their organisational model into various brands and how these models are configured within the CDR Register.
Entity Model
Data holders and data recipients are represented as legal entities and brands within the CDR 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 CDR Register. These brands are used to help segregate the different functions of the participant.
The ecosystem entities section of the CDR 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:
- 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)
- Differentiate between different software platforms and identity stacks within the organisation
- Differentiate between different consumer facing business brands within the organisation
- Capture non-designated white label brands the legal entity is responsible for
While data recipients MAY use brands to:
- Differentiate between different business brands within the organisation
- 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'
In the CDR Rules and CDR Register, ‘Data Holder’ refers to section 56AJ of the Competition and Consumer Act 2010 and the 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. In the context of the banking sector, a data holder is an authorised deposit-taking institution (ADI) or a relevant accredited data recipient (ADR). Data Holder Brands in the CDR Register 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 CDR 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 more to consider when identifying what brands exist within their organisation. The complexity lies with the different functions 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 expose this list of brands to the consumer as part of the consent flow.
Data holder brands discovery
The CDR Register exposes the GetDataHolderBrands API to enable accredited data recipients to discover the data holder brands active within the ecosystem. This is an authenticated API dedicated for this purpose.
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 CDR 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 banking 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
Legal entities with their associated brands (and software products where relevant) as well as their statuses, are published here for the general public to reference. The statuses for each of these entities is also published for reference.
The brands for each legal entity are displayed as follows:
Public CDR Register displaying a legal entity and the associated brands
Information stored against a data holder brand
The CDR 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 GetDataHolderBrands API.
Please refer to the Participant Endpoints section for further details.
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 CDR 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 CDR Register.
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 CDR Register Design and 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 Consumer Data Standards End Points section. 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 the Dynamic Client Registration section in the CDR Register design.
Product Reference Data
The PublicBaseUri provides reference to the endpoints used to host Product Reference Data (PRD). PRD data should not be combined with any other brand hosted on the CDR Register.
The product reference data brand feature in the GetProducts 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 CDR 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 GetMetrics 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 CDR 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 CDR Register.
This results in the following:
- Consumers will see these data holder brands as different entries during the consent flow and;
- 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:
- Each platforms is independently identifiable to the consumer (e.g. Demo Bank – Personal vs Demo Bank – Business), and;
- 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 CDR Register. Improvements to the CDR Register are planned to help accommodate this approach prior to the addition of energy to the CDR.
White Labels
White labelling brings a whole new set of scenarios to cater for in the Consumer Data Right. A dedicated article will be published outlining how the various white label scenarios published in Noting Paper 169 will be catered for on the CDR Register. Technical commentary on these scenarios has been authored in the article White Label Brands in the CDR.
Conclusion
The usage of brands within the Consumer Data Right ecosystem provides flexibility on how future models may be conveyed on the CDR 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 CDR Register design.
References
CDR Register Design |
https://consumerdatastandardsaustralia.github.io/standards/#register-apis |
CX Guidelines |
|
Consumer Data Standards |
|
Consumer Data Right Public Register |
|
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 |
Comments
0 comments
Please sign in to leave a comment.