OTP SMS codes for CDR consent should be independent of online banking SMS settings

[AdamGrockeSherlok]

Description

During the consent flow the customer is redirected to the lenders page to input their customer ID and to send the OTP. They are receiving confirmation from the lender on that page that the OTP has been sent via SMS but the customer never receives the SMS. See attached Screen shots.

In this instance, and we believe there are others across other lenders, the lender is not sending the OTP if the clients have online banking SMS/OTP settings turned off.

The customer needed to change their on-line banking SMS/OTP settings which was difficult and clunky and takes away from an easy UX.

Area Affected

Describe the area of the standard that is proposed to be amended. This could be one or more API end points or a specific section of the information security profile

Change Proposed

We are proposing that the CDR consent flow should be independent of the customers online banking settings EG: OTP should be independent of the online banking settings as the customer is giving explicit consent at that point in time through the CDR consent flow to issue a OTP via SMS to their mobile. This will significant improve the customer experience and simplicity of enabling the consent.

We to not suggest that providing the customer with a message to change their online banking settings for SMS/OTP as an acceptable change as this is clunky and detracts from a seamless UX and customer may want to maintain their current SMS/OTP settings post the CDR consent.

[perlboy]

This appears to run afoul of these statements in the Standards:

• Data Holders MUST provide a one-time password (OTP) to the customer through an existing channel or mechanism that the customer can then enter into the redirected page
• The delivery mechanism for the OTP is at the discretion of the Data Holder but MUST align to existing and preferred channels for the customer and MUST NOT introduce unwarranted friction into the authentication process

https://consumerdatastandardsaustralia.github.io/standards/#authentication-flows

[rob-hale]

I can see the appeal of the proposed approach for any ADR wishing to reduce friction and improve conversion. The redirect to the DH and the subsequent "fingers crossed" moment as the request goes off into the abyss, is definitely a problem, however...

• If DHs were to simply send an SMS OTP without considering existing customer communication preferences, that could create different problems - the customer may prefer an alternate OTP channel such as a virtual or physical token, email, or push notification via an app, or they may simply not want to receive SMS communication from that company. The DH should respect that choice.
• There may be a reason that a mobile number hasn't been selected or configured for SMS OTP. The customer may live in a remote area where SMS does not function reliably, it could be a shared number or it may simply not have been verified as belonging to that customer.
• The process of registering a number for SMS OTP with a DH typically involves a test message and some type of verification step. This does create friction, but it's an important step. Once verified, the DH has more confidence that the customer has the corresponding device in their possession and it can be used as a reliable second factor of identification.

That said, this issue is real. It touches on that more fundamental abyss issue.

If the ADR knew that the consumer had successfully been redirected to the DH, but had failed the SMS OTP step that would be helpful. It would be even more helpful if the ADR knew that there was no method through which an OTP could be sent to that consumer. This would enable more specific and useful feedback to be provided within the consent CX along the lines of "Your bank is unable to send an OTP to you at this time".

Unfortunately there is no information available to ADRs today to support this type of informed consumer messaging. Maybe that's the area we should be looking at - improving the messaging between ADRs and DHs when consent is first established. This is particularly important for certain use cases where the consent is established at the tail end of a lengthy process - such as a loan application. Failing at that point is particularly frustrating.

Perhaps a simple priming query could be used to check if a customer ID has one or more eligible accounts for a holder and is able to receive an OTP via an existing stated preference. If such a query was possible, it could be made earlier in a process, enabling a more graceful transition through an alternate application pathway. Maybe something for the consent optimisation working group to consider?

[jimbasiq]

I agree there is an issue here and our metrics show a high % of consumers failing data holder authorisation.

An option we could consider is the ability to use an alternative means to verify if the primary option is not successful. For instance using their registered email.

Another idea would be to use their Online Banking username and password. However this one would require a change to the rules I believe as they would not be using an OTP.

[AdamGrockeSherlok]

The Utopia IMO described as a problem statement..

How can we get the consent flow to be solely manage by the ADR's, TA, Fintech's UX/UI without the need for the consumer to interact with the DH portal/site etc?

This would solve several problems including the above. it would also allow greater consumer experience, increase conversion and remove fail points and second consents EG: if a consent failed due to the DH portal/connecting being down, we'd have the consent record and could reprocess/request the data at a later date.

[markskript]

For the ADR's to handle the consent flow without a handoff to the DH, especially if we want the ability to "reprocess" later on would require the ADR's to handle auth credentials on behalf of the user. This reminds me of screen scraping where I need to provide my IB username+password to a 3rd party, and is one of the key things we are trying to avoid here in the CDR IMHO. While the handoff to the DH does introduce the issues highlighted above, it also provides a key point of consumer confidence where they are only providing authenticating credentials directly to their DH and not to the ADR.

[TT-Frollo]

The overarching sentiment to improve consent success is spot on. Changing the OTP may be an answer.

I agree with Rob Hale's point: "Unfortunately there is no information available to ADRs today to support this type of informed consumer messaging. Maybe that's the area we should be looking at - improving the messaging between ADRs and DHs when consent is first established".

To that end a holistic look at where the issues with consent authorisation lie is needed.

If authorisations could log 3 statuses: OTP provided, accounts selected, consent confirmed or some other states and provide back to ADR if token creation not successful that would help. Many options exist but in order to triage consents not successful information must flow between ADR's and a DH. Even an initial tag passed from the ADR to the DH would be useful, it could be used in the event of triaging this scenario since an ADR cannot provide any information to a DH to look for the problem if they have no data such as client id to provide. Making raising a Jira ticket for this scenario pointless.

[spikejump]

In terms of getting informed messaging back to the consumer/ADR, all DHs really should make sure there is a redirect back to the ADR with proper error message as defined in OAuth and OIDC.

What we have observed is a lot of DHs don't implement a required redirect back to ADRs for errors (even user cancellation is a type of error). When such redirect happens, the DHs MUST populate the 'error' property and optionally the 'error_description' property. In most cases, DHs chose not to provide any description and so ADRs, when they do get an error redirect, are left not knowing precisely what happened and so can't properly advise the consumers on the failure.

If the DHs are required by the standard to populate descriptive information on the failure in 'error_description' then that will be a start to allow consumers to be better informed.

[TT-Frollo]

@spikejump, I agree the redirect back should properly include errors and descriptions. In the consent context, it seems though that whilst a user cancelling the authorisation flow should/must result in an error abandoning for other reasons is not considered by DH's as required nor enforceable.

No doubt the required information would be expensive for DH's to implement.

However, to the point of the issue. For trust to remain with the DH, they should authorise consents using existing customer channel identifiers.

Acknowledging that the OTP and technical issues with customers authorising a consent flow is one of the biggest problem we have atm. DH's should advise what they are doing to rectify/reduce the issue at the same time as new auth methods are canvassed such as app2app.

[perlboy]

Purveying information in the oauth2 error response is fraught with problems. On the one side it may be seen as informative on the other side an information security disclosure risk (because it's transmitted in the clear on front channel). There is definitely a need to communicate better information to the ADR but a back-channel mechanism that can be richer in quality and extensible into the next phase makes a lot more sense.