Clarification on how DR software and brand names are to be used in a CX context #222
Comments
ghost
added
the
CDR-API-Stream
added
the
Consumer experience
|
Hi @mattp-rab thanks for the query. This issue is currently under review by the @CDR-CX-Stream team. |
|
We agree that this issue will likely result in CX inconsistency and possible customer confusion where the software product name is different to the brand name. As such, we believe it warrants further consideration and a potential amendment to the CX and/or registry standards, in time. In the short term, we would recommend that:
ADH: ACME Bank ADR Software Product name 1 (proposed): Lux Solutions Lending application The upside of this approach is that ensures CX consistency across ADHs without considering a change to the standards whilst the downside is that the description could become quite lengthy and the CX subsequently clunky. In the longer term, we’d suggest consideration be given to additional metadata in the register describing the brand, product, purpose and possibly CX preferences associated with each software product which could be incorporated in the ADH’s CX flow. |
ResponseThe DSB has been working with the ACCC in response to this issue, and related issues that are expected to arise as the CDR begins to see more complex accreditation and collection models. Currently, data holders are required to present the name of the accredited person (or ADR) during the authorisation process and in the consumer dashboard. This refers to the accredited or legal entity rather than the brand name, software product name. Currently implementations are presenting an array of legal entity, brand name, and software product name, leading to inconsistency of presentation for ADRs. The DSB has considered the above scenarios in collaboration with ACCC. Following the publication of the v2 rules for consultation, we are now seeking community feedback on the below interim and future possibilities before considering the development of a formal proposal. The below items are preliminary concepts published for the purposes of discussion, and should not be considered formal proposals at this stage. Interim StateThe following is being considered as an interim state solution, which could be articulated as follows:
An example of how the above could work:
*Only 'The Fintech' would appear in the authentication, authorisation, and associated processes The DSB is interested in views on the suitability of the above interim solution, including if the above or any other appropriate solutions should be classed as optional or mandatory. The DSB is also interested in understanding any build impacts this may have, and how this model aligns with existing and expected ADR structures. Future StateA more sophisticated future state solution may be necessary as the CDR expands to include more complex accreditation, consent, and collection models. The proposed new rules contain changes that support this aim. Proposed rules 1.15(1), 4.23(2), and 7.9 seek to ensure data holders display additional information to consumers during the authorisation process and on consumer dashboards. This proposal is discussed in the CDR Rules Expansion Amendments Consultation Paper. These fields would be contained in the Register and relayed to the DH in the authorisation request, to be developed by the ACCC and DSB. This solution would allow ADRs to populate additional fields to be presented, which may include:
The 'Auth' and 'Consent Label' fields, if populated, could supersede the Brand and software product name fields to give ADRs greater flexibility in how they are presented by DHs in the consent model. These fields would be provided by the Register in which the superseding logic could occur to ensure data holders present the correct fields. The 'Co-Label' field, if populated, could consist of optional metadata contained in the authorisation request based on new technical data standards. This field could be used as an additional label for a consent; a way to label concurrent consents; or for any other additional information a consumer or ADR wants to use to label a consent A preliminary proposal for a future state could be articulated as follows:
An example of how this could work is demonstrated in item 7.5 in the v2 rules wireframes, which we encourage the community to review to understand how these fields could appear in the consent model based on different dashboard designs. The DSB is interested in views on the suitability of the above future state solution, including if the above or any other appropriate solutions should be classed as optional or mandatory. The DSB is also interested in understanding any build impacts this may have, and how this model aligns with existing and expected ADR structures. Any future state proposal will ultimately depend on the v2 rules consultation. Other considerationsAs noted by the community, there would still be a need for any ADR fields/labels to be succinct to display well throughout the consent model, while also being meaningful to consumers for consent management purposes. To support this, a naming convention during the ADR onboarding process is being considered, along with a UI demo tool to help ADRs understand how and where their name choices will appear in the consent model. These will be considered as a separate item to this issue, but comments from the community on how to facilitate these objectives are also welcome. FeedbackThe DSB is seeking community feedback on the above possibilities before considering the development of a formal proposal. These are preliminary concepts published for the purposes of discussion, and should not be considered formal proposals at this stage. If a proposal emerges from the discussion on this issue it will be proposed and consulted on separately. |
|
Suncorp recommends that all considerations in the interim state solution be optional, due to the potential of the interim solution becoming superseded when the future state is effective. Using the brand name (or any name) in the OTP delivery would have major impacts on our solution. It means we would not be able to use existing methods for providing the OTP which would cause unnecessary friction to the user. In the authenticate flow the customer is advised how to retrieve their OTP, so adding the brand name to the OTP delivery has minimal customer experience benefits. |
|
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. |
Use of DR software and brand names within DH CX
As a Data Recipient wishing to ensure consistent use and presentation of our Software Product Name and Associated Brand, Regional Australia Bank is seeking clarification on how these data elements should be displayed by DHs in consumer-facing interfaces (DH portals). At present, while slides 71 and 72 of the CX Guidelines touch on the matter with some illustrated examples, there is no prescriptive guidance and consequently, display of these attributes is open to interpretation.
In UAT implementations to date, this has resulted in an inconsistent representation of DR brands and software products across DHs with some instances being nonsensical. Without guidance, this will potentially devalue/violate DR brand guidelines and confuse consumers, diminishing trust and the overall reputation of the CDR ecosystem and participants.
It is also challenging for DRs to settle on precise wording when registering their software products, without understanding the context within which these attributes will be presented publicly.
Here are 3 examples (there are many more) to illustrate. Any and every combination of Associated Brand, Software Product Name, or a concatenation of these is currently possible.
The DH asking a customer to provide their ID to connect to the DR
The DH confirming if a consumer cancels prior to connecting to the DR
The DH confirming to a consumer that a DR is an accredited DR
There are also potential associated issues that require addressing, such as string length and the need to avoid over-crowding / cluttering the consumer UI with unnecessary content.
So, could guidance be provided as to how these DR software product attributes are to be surfaced within the DH CX layers to ensure contextually correct presentation?
The text was updated successfully, but these errors were encountered: