CX Guideline Clarification - Unique Identifier

[jakubvozarik]

The CX Guidelines for unique identifier in authentication flow state:

Data holders MUST request a user identifier that can uniquely identify the customer and that is already known by the customer in the redirected page.

Does that meant that this unique identifier must be a single value that customer enters or can multiple values be used to authenticate a customer (such as a card number + date of birth combination) ?

[CDR-API-Stream]

Hello @jakubvozarik this issue has been moved to the Standards Maintenance repository. This issue will be addressed here.

Queries and change requests are being addressed in the Standards Maintenance repository. In future it would be appreciated if you could post your questions there and the DSB will respond to them.

[CDR-CX-Stream]

Hi @jakubvozarik, the standards state 'Data Holders MUST request a user identifier', but the standards do not require that a single attribute be used as the identifier.

The expectation is that any user identifiers be familiar and align with existing experiences as well as consumer expectations and preferences. The CX Guidelines example a single identifier with these factors in mind.

To help the DSB better understand this use case it would be useful to know if, where, and why requiring multiple values, including the example given, would be a common authentication scenario.

[jakubvozarik]

Hi @CDR-CX-Stream - thanks for your response.

There are two main reasons why we are considering using multiple attributes:

1) Replicate existing customer experience for online transactions: We want to replicate the current customer experience when performing any online transaction on a third party site, and utilize the customers debit/credit card details to perform the authentication. This includes a combination of card number, CVV and One-Time PIN. Customers are more accustom to sharing these type of information on third-party websites when performing online transaction such as retail purchases and BPAY, rather than being asked to enter their Online login credentials that belongs to another financial institution. Also, only providing card number does not guarantee an exact match to a single customer, as the concept of card number can also be reference to an Account number which is shared across a Primary & Additional cardholders.

2) Other types of single identifier

Online login credential: The standard thought in today’s Digital environment would be that all customers are currently using Online or Mobile channel to perform their banking. However, not all customers have created an Online Banking account nor are Digitally active users. Hence, our view to ask customers whom want to share their data to first either create an Online account or perform steps to recall their Online User login details with the Data Holder would be a constraint to the end-goal to become an open economy.

Customer ID: We have observed various banks sharing their internal customer ID to their clients. However, this is not a standard practice across the banking industry and there are many organisations (including ourselves) where this customer ID is not shared to the customers

[CDR-API-Stream]

Hi @jakubvozarik,

Re: Customer ID Banks are not using an internal customer identifier, they are using the customer's internet banking ID, often referred to as a Customer ID. Banks may support different user identifiers to access their digital services (e.g. email address).

Aligning to existing digital services Whilst you make mention to "Replicate existing customer experience for online transactions", that is not what the CDR is trying to do. The CDR should align with existing customer experiences for accessing digital services (e.g. internet banking). These two things are very different.

Choosing the right Customer ID/User Identifier As @CDR-CX-Stream mentioned, the CX Guidelines show a single user identifier for the Customer ID. This is because it is the most commonly accepted form for access to digital services. However they go on to state that the "standards do not require that a single attribute be used as the identifier".

• The statement that the customer should be asked for a unique identifier that is already known is deliberately vague to give DHs flexibility because there are many different models for how people are asked to login by banks. Effectively, the choice of identifier is left to the DH.

• This does not presuppose the use of a single identifier, although that is most likely to be the case for the majority of banks.

• The regime as a whole has had significant concerns about increased phishing risk. Asking people for a Credit Card number on authentication on a website that has automatically popped up from an arbitrary mobile app would not be considered best practice. The use of credit card details would not be suitable.

Further background

• It is known that not all bank customers have a registered online experience. The position has been that customers without an internet banking login experience should be invited to register and then they can share their data after they have registered.

• The data standards specifically allow for the DH to define the concept of customer so they can, at their discretion, ask additional profile related questions once authentication has occurred (such as, do you want to operate in a personal or business context, or which business are you wanting to share data for).

Follow up and next steps To help the DSB better understand this use case it would be useful to know if, where, and why requiring multiple values, including the example given, would be a common authentication scenario for digital services.

[jakubvozarik]

Thank you @CDR-API-Stream for the detailed response

One reason why we are exploring the use of other identifiers which are not linked to an Online credential, is based on some white-label arrangement, customer have Online credential held with the Brand Owner and not the Data holder.

Based on the presentation by ACCC on Thursday 07/05/20, the direction is for the White-labeller (i.e. Data Holder) would be responsible to comply to CDR rules, which creates multiple questions in terms of how these customers would be service:

1. Would the data holder need to issue a new Online credential to the customer in the lead up to the Consumer data sharing commencement date
2. How would customers know which Online credential to use, given they may now how 2 sets: a) Online credential with Brand owner; b) online credential with Data holder

[CDR-API-Stream]

The DSB are now responding to requests for clarification via the CDR support portal. If this question is still applicable, it would be appreciated if you could raise your request there as it will likely be responded to in a more timely fashion and the resulting answer can be turned into an article for others with the same question.