-
Notifications
You must be signed in to change notification settings - Fork 9
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
List of accounts to show in the Consent Flow #313
Comments
An additional question in this space based on how the data holders may have done the account association(s) with their channel identifiers. John is a customer of Data Holder and he has two internet banking credentials - 10099999 & 99911111 each of these are associated with the 000999101 and 000888101 and 999888101 and 999888102 (represented in the picture below) When John enters the User Identifier - 10099999 during the DH authentication flow what is the expectation on the list of accounts returned? All 4 accounts:
or just the two accounts that the User Identifier 10099999 is associated with. My reading is that John is the customer and he is using an identifier that he knows with the Data holder to identify himself. The preferences and other semantics that the Data holder channel (Internet Banking in this case) should not influence the list of accounts returned - i.e all eligible accounts associated with John should be returned Will appreciate the viewpoints and interpretations of the experts here. |
I'm not the expert here, but I can share my thoughts to see if they help. Re: your point (2a) above, you mentioned -
In that case I guess it couldn't appear in the list, unless you have another way to match it to the customer credential? Re: (2b), my first thought was this part of the rules, the last line here -
But that is about eligibility for consumers, not specific accounts. In your example the customer would be 'eligible' because they have at least one online account. Whether the other account should be included may be up to you if you are aiming to match online banking and the customer has chosen not to "set up in such a way that it can be accessed online". As you have stated it is the customer preference - I'm guessing the customer could change their preference and attempt sharing again if they really wanted to share that account? There may be another aspect to this in the below rule and I'm not sure if this is where your concern came from?
I'm not sure if there's any more clarity available on the "cannot be accessed online" part of that note. (extracts from rules) I think the key to your additional question is that you are allowed to show some kind of profile selection screen where necessary and also with concurrent consent, the customer could create a different consent for each identifier they normally use. If the customer has different credentials for different reasons, they may not want/expect all their accounts to be grouped together in CDR if they are not normally like that in their online banking view. Are any of these points helpful or incorrect to your understanding? |
Hi @bmangalaganesh thanks for your patience. Please see below the response from the ACCC.
|
Request For Clarification
I am trying to better understand an edge case scenario - "list of accounts" to display during the consent flow.
Both the accounts listed below are Transaction account(s) which makes them an eligible account (available in the current phase of products that are supported by CDR)
There are a couple of variants in which account 222333444 has been set up at the data holder?
There is no ambiguity about displaying the account 123456789 during the consent flow.
What about the account - 222333444?
Should that be displayed in the list of accounts in consent flow in both (2a) and (2b) variants?
Appreciate any help.
The text was updated successfully, but these errors were encountered: