Skip to content

Decision Proposal 256 - Telco Endpoints #256

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
CDR-API-Stream opened this issue Jun 6, 2022 · 7 comments
Closed

Decision Proposal 256 - Telco Endpoints #256

CDR-API-Stream opened this issue Jun 6, 2022 · 7 comments
Labels
Category: API A proposal for a decision to be made for the API Standards made Industry: Telecommunications This proposal impacts the telecommunications sector Status: No Decision Taken No determination for this decision has been made

Comments

@CDR-API-Stream
Copy link
Contributor

CDR-API-Stream commented Jun 6, 2022

This decision proposal contains a recommendation for the candidate URIs for the telecommunications sector.

The decision proposal is embedded below:
Decision Proposal 256 - Telco End Points.pdf

This consultation will be open for feedback until the 12th August 2022.

@CDR-API-Stream CDR-API-Stream added Category: API A proposal for a decision to be made for the API Standards made Status: Proposal Pending A proposal for the decision is still pending Industry: Telecommunications This proposal impacts the telecommunications sector labels Jun 6, 2022
@CDR-API-Stream CDR-API-Stream changed the title Decision Proposal <Number> - Telco Placeholder 2 Decision Proposal 256 - Telco Placeholder 2 Jun 6, 2022
@CDR-API-Stream CDR-API-Stream changed the title Decision Proposal 256 - Telco Placeholder 2 Decision Proposal 256 - Telco End Points Jun 15, 2022
@CDR-API-Stream CDR-API-Stream changed the title Decision Proposal 256 - Telco End Points Decision Proposal 256 - Telco Endpoints Jun 15, 2022
@CDR-API-Stream CDR-API-Stream added Status: Open For Feedback Feedback has been requested for the decision and removed Status: Proposal Pending A proposal for the decision is still pending labels Jun 27, 2022
@cybertrekman
Copy link

TPG Telecom have an issue with the approach taken to create standards before the rules are known. We would expect that to have a meaningful dialogue regarding the standard requires rules to be in place otherwise comments on the standards are rather pointless. The telco market is quite unlike banking or energy, yes we have customers and authorised rep's, but we also have arrangements for sharing the product purchased between parties that may only be loosely associated, for example; a customer can purchase a product from one telco that allows donation of unused available data to anyone with service with the same service provider. There should be no expectation that a customer sharing their spare data allowance with another customer enables either party to view information relating to either party. Telco's regularly have special offers and plans that provide free use of the service for a short period, and/or half price or double allowances for use for a specified period. Telco's have a range of plans that result in some customers having multiple services (fixed, local, broadband) on a single account, or on multiple accounts, the product construct is based on the service (Note: document 256 seems to have this switched about), where a product set then depends upon whether the service is paid as a post paid, pre-paid or hybrid of both (i.e. some parts of the service paid in advance and usage assessed at the end of a set period) and the product is the amount paid for the service at a set interval that may be 7 days, 28 days, quarterly, bi-annual or annual. Generally customers are not locked into plans (product) and this can vary month to month e.g. a customer may know they are going to need more capacity in a given month and may choose to upgrade their plan for that month, or the opposite. Customers can also readily change the interval period and product at any time, for example a customer may be on a 7 day plan to trial a service and then switch to a monthly or longer interval plan, or a customer on a long payment interval plan may choose to switch to a shorter duration plan at any time before expiry of the plan. We are therefore unclear how this relates to the expectations of the CDR scheme and how this relates to the standards. Also, large corporate and government entities have unique plans to suit their needs and CDR will have no benefit to this category of consumer but the effort required to incorporate this category of customers into CDR will be quite significant.

TPG Telecom (TPGT) has the following specific comments on Document 256
Current recommendation
In creating the recommendation, the following relationships between data sets has been assumed. The validity of these assumptions is a fundamental aspect of this proposal and feedback is specifically sought on these points:
• A customer may be an individual or a business (in which case data sharing is being authorised by an authenticated and authorised agent)
TPGT – Further define 'customer'', customer may or may not be the end user or end user of all services? Shared family, small business accounts, guardians, etc. What association between 'customer' and end user? What are rights of end user to access data? How are customers considered when both parties are only loosely associated by being customers of the same service provider. What are the Privacy arrangements for many end users and customers who are unrelated?

The following two points are back to front (i.e., customers have services (e.g., mobile, mbb, local, nbn, etc. Each of these service types will have a different product offering (e.g., mobile $40 month postpaid, mobile $35 28 day prepaid, etc.).
• A customer must have one, but may have many, products
TPGT – Yes, but telco's define products by hierarchy – generally a product is relevant to the service, then ancillary products e.g., comms product such as $40 month postpaid for comms usage then ancillary products that may be used in association with that service (e.g., direct carrier billing such as subscription service like; Amazon Music, Netflix, Stan, Kayo, Google Play store, etc.)

• A product must have one, but may have many, associated services
TPGT - Define service – telco services are those with a unique identifier such as a phone number or other unique number, local service, fixed service, MBB, nbn, etc. The unique number is variable based on the type of service e.g;, ten digit public number or a unique number associated to a mobile or fixed network broadband service - there is no standard for the length of a unique identifier associated with a broadband service

• Usage data is attributable to one, and only one, service
TPGT – Not always true in a bundled service arrangement and not always captured (e.g., an all you can eat service is not billed per usage and no usage data is required to be retained). Data can also be shared or donated among different customers with the same service provider.

• Billing charges may arise that are unrelated to usage (such as fees)
TPGT – Yes, Direct Carrier Billing (DCB) enables a telecommunications account to include subscription services and payments for small items on an ongoing or ad-hoc basis e.g., accessories, Google Play, etc. . The fact that a telco. is simply providing a billing solution for charges in one place, that the subscription service cost is generally the same regardless of supplier and given the ad-hoc nature of these billing charges and their variability over time their inclusion into CDR seems rather pointless and potentially restrictive of future product offerings.

• Payments are attributable to one, and only one, customer
TPGT – Mostly, but not always. A payment made is not always the full amount as the customer may part pay their account. In case of a disputed charge the customer does not pay that part of the bill. In other cases a customers may only part pay their account and have balance paid by one or more other parties, Or, customer may either regularly, or in an ad-hoc approach, pay for the service of another customer, who may only be loosely associated to them, such as in sharing arrangements (e.g., pass on credit to another service) or in times of natural disaster telco's may offer an ability for a customer to pay a little more to pay or part pay account of a person unassociated to them.

• Current balance is attributable to one, and only one, service
TPGT – No. Telco. bill can have a multi service account. And there's a considerable difference between prepaid and post paid accounts. A prepaid has a concept of a current balance a post paid generally does not. There are also hybrids where some of these service charges are billed in advance and others paid in arrears (e.g., TPG charge a monthly fee in advance and bills some call usage e.g., overseas calls, in arrears).

P.8
Account Data
Title Obtain a list of the established accounts with the service provider for the current customer
HTTP Method GET
UR /telco/accounts
Security Scope telco:accounts.basic:read
Description
This end point provides the list of accounts held by the current customer with the telco for which consent has been established. Unlike other sectors the full list of established accounts is expected to be shared in all cases if the valid scope has been consented to. In most cases it is expected that only a single account per customer exists. Only basic information is returned from this end point. This basic information will include the services that the account covers.

TPGT - Customers can have many accounts (e.g. customer may have many single prepaid services or individual accounts for mobile, fixed, mbb, nbn, etc.) A customer with many accounts may or, may not be identifiable under the exact same name and the address may also vary (e.g. Mary Smith, Mary Jane Smith, Mary Brown (married name), Pravin Josuva Deepak, Deepak Pravin Josuva, etc.).

Title
Obtain the details for a specific account that the current customer has with the retailer

Description This end point provides detailed information on a specific account data held by the current customer with the telco for which consent has been established. The additional detailed information will include the contracted product(s) for the account (including data, tariffs, fees and features) as well as the current balance of the account. This end point will not contain personal or contact information. This is accessible under the customer end points.

TPGT - What are the customer authentication arrangements?
How do we ensure that this is not used to breach knowledge factor information used as part of ACMA customer Authentication obligations to stop fraud and scams?

P.9
Title
Obtain the invoices for all accounts
This end point provides invoices on all accounts held by the current customer with the telco for which consent has been established. This end point will support pagination and filtering

TPGT - What are the customer authentication arrangements (same issue as above)?
How do we supply this when there is no bill (e.g. set amount at a defined periodicity)
Note numerous items follow in this document all based on premise of a bill or bill content, such as usage data (e.g., calls, data use, etc.) where none may exist.

We really need to understand the rules before being able to provide further comment on standards that do not reflect telecommunications arrangements. There is still no business case for CDR that appears to be a solution looking for a problem to solve and where in the telecommunications sector there is not an identified problem. Customers have ready acces to billing data and we have had number transfer arrangements for over 20 years and competition in the telecommunications market means new services and products are constantly changing to add more value, add additional benefits and reduce costs. CDR has a risk of creating a stopper on innovation if we have to adhere to a defined structure outside of the control of the service provider delivering the service.

@CDR-API-Stream
Copy link
Contributor Author

In response to @cybertrekman:

TPG Telecom have an issue with the approach taken to create standards before the rules are known. We would expect that to have a meaningful dialogue regarding the standard requires rules to be in place otherwise comments on the standards are rather pointless. The telco market is quite unlike banking or energy, yes we have customers and authorised rep's, but we also have arrangements for sharing the product purchased between parties that may only be loosely associated, for example; a customer can purchase a product from one telco that allows donation of unused available data to anyone with service with the same service provider. There should be no expectation that a customer sharing their spare data allowance with another customer enables either party to view information relating to either party. Telco's regularly have special offers and plans that provide free use of the service for a short period, and/or half price or double allowances for use for a specified period. Telco's have a range of plans that result in some customers having multiple services (fixed, local, broadband) on a single account, or on multiple accounts, the product construct is based on the service (Note: document 256 seems to have this switched about), where a product set then depends upon whether the service is paid as a post paid, pre-paid or hybrid of both (i.e. some parts of the service paid in advance and usage assessed at the end of a set period) and the product is the amount paid for the service at a set interval that may be 7 days, 28 days, quarterly, bi-annual or annual. Generally customers are not locked into plans (product) and this can vary month to month e.g. a customer may know they are going to need more capacity in a given month and may choose to upgrade their plan for that month, or the opposite. Customers can also readily change the interval period and product at any time, for example a customer may be on a 7 day plan to trial a service and then switch to a monthly or longer interval plan, or a customer on a long payment interval plan may choose to switch to a shorter duration plan at any time before expiry of the plan. We are therefore unclear how this relates to the expectations of the CDR scheme and how this relates to the standards. Also, large corporate and government entities have unique plans to suit their needs and CDR will have no benefit to this category of consumer but the effort required to incorporate this category of customers into CDR will be quite significant.

This appears to be a duplicate of the feedback on the customer consultation. We have responded to this feedback on that consultation thread : #257. Please refer to our comments there.

@CDR-API-Stream
Copy link
Contributor Author

In response to @cybertrekman:

TPG Telecom (TPGT) has the following specific comments on Document 256 Current recommendation In creating the recommendation, the following relationships between data sets has been assumed. The validity of these assumptions is a fundamental aspect of this proposal and feedback is specifically sought on these points:

  • A customer may be an individual or a business (in which case data sharing is being authorised by an authenticated and authorised agent)

TPGT – Further define 'customer'', customer may or may not be the end user or end user of all services? Shared family, small business accounts, guardians, etc. What association between 'customer' and end user? What are rights of end user to access data? How are customers considered when both parties are only loosely associated by being customers of the same service provider. What are the Privacy arrangements for many end users and customers who are unrelated?

Under any single disclosure consent under the CDR there are exactly two identities that are relevant: the person sharing the data (the consumer granting consent) and the customer they are sharing data for (as understood by the data holder). In the retail or mass market context these two identities are always the same. In a business context they are different with the customer being the business or organisation and the person granting consent being a nominated representative of that business or organisation.

The CDR rules currently cover the concept of nominated representative fully in generic (ie. cross sectoral) rules. It would be helpful to understand if those rules do not sufficiently cover the complexity that TPG currently supports. We would be happy to pass that feedback on to the rules team.

Other people that may have access to, or rights concerning a customer or account are covered by the rules and technical mechanisms already developed for banking and energy. These different models are addressed in the rules under the banner of Joint Accounts and Secondary Users. Again it would be helpful to understand if those rules do not fully cover the complexity you are referring to.

On a superficial review of your feedback we can identify corollary patterns that already exist in banking and energy but this review could be incorrect without understanding the detail better.

@CDR-API-Stream
Copy link
Contributor Author

In response to @cybertrekman:

The following two points are back to front (i.e., customers have services (e.g., mobile, mbb, local, nbn, etc. Each of these service types will have a different product offering (e.g., mobile $40 month postpaid, mobile $35 28 day prepaid, etc.).

This is helpful. We debated this one internally. We will look to incorporate this feedback.

  • A customer must have one, but may have many, products

TPGT – Yes, but telco's define products by hierarchy – generally a product is relevant to the service, then ancillary products e.g., comms product such as $40 month postpaid for comms usage then ancillary products that may be used in association with that service (e.g., direct carrier billing such as subscription service like; Amazon Music, Netflix, Stan, Kayo, Google Play store, etc.)

  • A product must have one, but may have many, associated services

TPGT - Define service – telco services are those with a unique identifier such as a phone number or other unique number, local service, fixed service, MBB, nbn, etc. The unique number is variable based on the type of service e.g;, ten digit public number or a unique number associated to a mobile or fixed network broadband service - there is no standard for the length of a unique identifier associated with a broadband service

This is extremely helpful feedback. Thank you. We will seek to understand this and incorporate it into the final position.

  • Usage data is attributable to one, and only one, service

TPGT – Not always true in a bundled service arrangement and not always captured (e.g., an all you can eat service is not billed per usage and no usage data is required to be retained). Data can also be shared or donated among different customers with the same service provider.

We will incorporate this

  • Billing charges may arise that are unrelated to usage (such as fees)

TPGT – Yes, Direct Carrier Billing (DCB) enables a telecommunications account to include subscription services and payments for small items on an ongoing or ad-hoc basis e.g., accessories, Google Play, etc. . The fact that a telco. is simply providing a billing solution for charges in one place, that the subscription service cost is generally the same regardless of supplier and given the ad-hoc nature of these billing charges and their variability over time their inclusion into CDR seems rather pointless and potentially restrictive of future product offerings.

This is helpful confirmation

  • Payments are attributable to one, and only one, customer

TPGT – Mostly, but not always. A payment made is not always the full amount as the customer may part pay their account. In case of a disputed charge the customer does not pay that part of the bill. In other cases a customers may only part pay their account and have balance paid by one or more other parties, Or, customer may either regularly, or in an ad-hoc approach, pay for the service of another customer, who may only be loosely associated to them, such as in sharing arrangements (e.g., pass on credit to another service) or in times of natural disaster telco's may offer an ability for a customer to pay a little more to pay or part pay account of a person unassociated to them.

We will incorporate this

  • Current balance is attributable to one, and only one, service

TPGT – No. Telco. bill can have a multi service account. And there's a considerable difference between prepaid and post paid accounts. A prepaid has a concept of a current balance a post paid generally does not. There are also hybrids where some of these service charges are billed in advance and others paid in arrears (e.g., TPG charge a monthly fee in advance and bills some call usage e.g., overseas calls, in arrears).

Very helpful. This is a complexity we will need to ensure we incorporate into the entity model

P.8 Account Data Title Obtain a list of the established accounts with the service provider for the current customer HTTP Method GET UR /telco/accounts Security Scope telco:accounts.basic:read Description This end point provides the list of accounts held by the current customer with the telco for which consent has been established. Unlike other sectors the full list of established accounts is expected to be shared in all cases if the valid scope has been consented to. In most cases it is expected that only a single account per customer exists. Only basic information is returned from this end point. This basic information will include the services that the account covers.

TPGT - Customers can have many accounts (e.g. customer may have many single prepaid services or individual accounts for mobile, fixed, mbb, nbn, etc.) A customer with many accounts may or, may not be identifiable under the exact same name and the address may also vary (e.g. Mary Smith, Mary Jane Smith, Mary Brown (married name), Pravin Josuva Deepak, Deepak Pravin Josuva, etc.).

That is good to know. The API structure is already designed to accommodate multiple accounts per customer so this should not be a problem. It is helpful to know that this is common, however.

Title Obtain the details for a specific account that the current customer has with the retailer

Description This end point provides detailed information on a specific account data held by the current customer with the telco for which consent has been established. The additional detailed information will include the contracted product(s) for the account (including data, tariffs, fees and features) as well as the current balance of the account. This end point will not contain personal or contact information. This is accessible under the customer end points.

TPGT - What are the customer authentication arrangements? How do we ensure that this is not used to breach knowledge factor information used as part of ACMA customer Authentication obligations to stop fraud and scams?

P.9 Title Obtain the invoices for all accounts This end point provides invoices on all accounts held by the current customer with the telco for which consent has been established. This end point will support pagination and filtering

TPGT - What are the customer authentication arrangements (same issue as above)? How do we supply this when there is no bill (e.g. set amount at a defined periodicity) Note numerous items follow in this document all based on premise of a bill or bill content, such as usage data (e.g., calls, data use, etc.) where none may exist.

Customer authentication is handled under the information security profile which is common for all sectors. CDR largely leaves the authentication step to data holders.

@CDR-API-Stream
Copy link
Contributor Author

To allow for more dialogue now that feedback is starting to come through we will extend this consultation by a week

@LeanneVOD
Copy link

"Usage data is attributable to one, and only one, service"

  • Note usage data is not provided on the customer's invoice for all unlimited NBN broadband products.

"Current balance is attributable to one, and only one, service"

  • dodo/iPrimus customers can have more than one telecommunications service on their bill

"Billing charges may arise that are unrelated to usage (such as fees)"

  • correct, for example iPrimus customers may have a Fetch TV service bundled with their broadband service and pay subscriptions for certain channel packs

"Obtain the invoices for all accounts"

  • dodo customers may also have separate energy accounts. The telco and energy services are billed separately (separate invoices) but the customer may receive a discount on their internet service if they also have an energy service, see: https://www.dodo.com/bundle

"A customer must have one, but may have many, products. A product must have one, but may have many, associated services"

  • Agree with TPGT feedback, a customer must a service (eg NBN, mobile) and each of these will have different product offerings. Customers may think of these "products" as plans as that is how they are often advertised by telcos.

@CDR-API-Stream
Copy link
Contributor Author

Thanks everyone for the helpful feedback. The feedback will be incorporated and draft standards will be published representing the progressive position of the evolving Telco standards in due course.

This consultation will now be closed.

@ConsumerDataStandardsAustralia ConsumerDataStandardsAustralia locked and limited conversation to collaborators Aug 14, 2022
@CDR-API-Stream CDR-API-Stream added Status: Feedback Period Closed The feedback period is complete and a final decision is being formulated and removed Status: Open For Feedback Feedback has been requested for the decision labels Aug 14, 2022
@CDR-API-Stream CDR-API-Stream added Status: No Decision Taken No determination for this decision has been made and removed Status: Feedback Period Closed The feedback period is complete and a final decision is being formulated labels Oct 27, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Category: API A proposal for a decision to be made for the API Standards made Industry: Telecommunications This proposal impacts the telecommunications sector Status: No Decision Taken No determination for this decision has been made
Projects
None yet
Development

No branches or pull requests

3 participants