About this list
This page provides brief explanations of commonly used terms in the Consumer Data Right. Many of the terms used on the performance dashboard are also explained on this page.
| Term | Explanation |
|---|---|
|
Accredited Data Recipient (ADR) |
A legal entity that can receive a consumer’s data under the Consumer Data Right and use that data to provide the consumer with goods and services with the consumer’s consent. ADRs must meet strict criteria to be accredited by the ACCC. |
|
Application Programming Interface (API) |
A common interface or intermediary that enables two or more software applications to communicate with each other and exchange data. APIs are a structured way to represent data stored in a database. The Data Standards specify the APIs through which data holders offer consumer data to ADRs. |
|
API endpoint |
A virtual gateway, URL or web address that allows different software applications to communicate and exchange data with each other. Data holders implement API end points to allow ADRs to access consumer data. |
|
API Invocation |
A request or ‘call’ by one software application for specific information from another application using an API. ADRs use API invocations to request consumer data from data holders. The ‘API Invocation’ metric measures the total number of API calls made by ADRs to data holders in each performance tier over time. |
|
Availability rate |
A metric that measures how frequently a data holder’s API end points are available to service consumer data requests from ADRs and deliver consistent and reliable access to consumer data in response. |
|
Average Response [Time] |
A metric that measures how long it takes for a data holder’s API end point to respond to an API invocation from an ADR. Factors such as data latency and timeouts can impact the accuracy of this metric. This time is measured in seconds, at millisecond resolution, at each performance tier. |
|
Brand |
CDR brand refers to the brand name of a data holder registered in the CDR Register. Brands help to identify the different products offered by data holders within the same sector (e.g. business banking products and retail banking products) and across different sectors (e.g. banking products and energy products). |
| Term | Explanation |
|---|---|
|
Consumer Data Right (CDR) |
The Consumer Data Right is an opt-in service giving consumers the choice about whether to share their data with full visibility of who it's being shared with and the purpose for sharing it. |
|
Consumer Data Right Rules |
Competition and Consumer (Consumer Data Right) Rules 2020 (Cth) |
|
Consumer Consents |
A consent is a permission given by a consumer to an ADR to collect, use and disclose their data. The ‘Consumer Consents’ metric records the total number of active consumer consents that are present with a data holder. |
|
Data Holder (DH) |
A legal entity that holds a consumer’s data – for example, a financial institution, such as a bank, that holds a consumer’s account information, or a utility company that holds a consumer's energy usage data. Data holders are subject to data sharing obligations under the CDR Rules. |
|
Data Standards |
The Consumer Data Standards are standards that data holders and ADRs must follow. They are available at consumerdatastandardsaustralia.github.io/standards |
|
Error |
An error is an error response that an ADR may encounter when calling an API offered by a data holder. Errors include client-side problems, server-side problems and authentication issues. Errors typically arise where an ADR uses incorrect syntax to request customer information. An error response can include an HTTP status code, such as “500 Internal Server Error”, which indicates that the relevant server was unable to process the request due to an internal server error. The ‘Error’ metric details the total number of API end point calls that resulted in error due to server execution over time. |
| Term | Explanation |
|---|---|
|
High Priority API |
The high priority APIs defined in the Data Standards include: In the banking sector:
In the energy sector:
Across both the banking and energy sectors:
|
|
Invalid data |
A value that records where performance or availability information provided by a data holder does not meet the validation criteria. |
|
Large Payload API |
An API call which is capable of returning a large data response that would reasonably impose higher data retrieval times on the resource server. Typically, API calls that are made to bulk request API end points. The large payload APIs defined in the Data Standards include any unattended calls to the following end points: In the banking sector:
In the energy sector:
|
| Large Secondary Invocation |
In the context of the energy sector within the CDR system, the Large Secondary API Invocation categorises large requests from the data recipient to the primary data holder, and then from the primary data holder to the secondary data holder to retrieve consumer data. Large Secondary Requests defined in the Data Standards are: Unattended calls to the following end points:
All calls to the following end points:
|
|
Legal Entity |
A legal person (an individual, company, other incorporated body or government entity). |
|
Low Priority API |
The low priority APIs defined in the Data Standards include: In the banking sector:
In the energy sector:
|
| Term | Explanation |
|---|---|
|
No Data Provided |
A value in the Performance Dashboard that records where a data holder has not provided any data or valid data on performance or availability. |
|
Peak Transactions per Second |
A performance metric for the maximum number of data transfers processed by a data holder in a single second over a given period, typically a day. It is used to evaluate the processing power and scalability of a data holder’s systems. |
| Primary Data Holder | Under the CDR system, a primary data holder in the energy sector is an energy retailer with whom the consumer has a direct relationship. |
|
Recipient Count |
The number of ADRs with active consumer consents at the time of an API call. |
| Secondary Data Holder | In the context of energy sector, the Australian Energy Market Operator (AEMO) is a secondary data holder. AEMO does not have a direct relationship with consumers, however, it possesses important consumer data not held by the consumer's energy retailer. |
| Secondary Invocation |
In the context of energy sector within the CDR system, the Secondary API Invocation categorises requests from the data recipient to the primary data holder, and then from the primary data holder to the secondary data holder to retrieve consumer data. Secondary Requests defined in the Data Standards are Customer Present calls to the following end points:
|
|
Session Count |
A session is defined as the life span of a unique Access Token. Multiple API requests made with a single, valid, Access Token during its life span are considered part of a single session. The ‘Session Count’ metric records the number of sessions over time. |
|
To Validate |
A value indicating that performance or availability data was received from a data holder outside of the expected range. |
|
Transactions per second (TPS) |
A performance metric that measures how many data requests an API offered by a data holder can handle and process within one second averaged over a given period, typically a day. |
|
Unattended API |
An API request made by an ADR ‘offline’ – i.e. a request that is not in direct response to interactions by the end customer. Unattended API requests are often made to support batch or pre-processing – for example, an accounting package may request data about previous day transactions overnight to allow for automatic posting. |
|
Unauthenticated API |
An API request made by an ADR to an API end point that the Data Standards deem to be publicly available (i.e. that is accessible without performing any authentication or authorisation actions). |