Consent conflict resolution

[valb3r]

trafficstars

As we aim to have the model of Many-To-One on FinTech->OpenBanking side and because there can exist only one consent for TPP, so that One-To-One is on (PSU,TPP)->ASPSP, we need to decide how to resolve consent conflicts.

[valb3r]

@francis-pouatcha @DG0lden Hi all, here is the consent access level model of XS2A interface of BerlinGroup (allPsd2 has more power than allAccounts and it can do everything allAccounts can do):

                    allPsd2
                /            \
               /              \
              /                \
allAccountsWithBalances      Dedicated
           |                /         \
     allAccounts           /           \  
                       IBAN123    IBAN235, IBAN678

The question is:

How we are going to solve the issue when:

1. FinTech-One asks for allAccounts and receives the consent
2. Then, FinTech-Two asks for Dedicated consent on IBAN123 (all transactions and balances)

The only solution within XS2A is to ask the user for allPsd2 consent for FinTech-Two (and only if ASPSP supports it)

Should we follow the strategy to ask for consent with greater scope in case of conflicts or we should fail the request?

[DG0lden]

This question is strongly dependent on how strict a bank follows the BG prescriptions.

It is worth to mention, that I'm not sure that there is a requirement in PSD2 for one consent per PSU per TPP (at least I don't know about it).

Therefore, the following scenarios can happen:

1. Bank supports several consents (either it doesn't follow BG requirement or it doesn't use BG at all). Then we shall allow Fintechs to create several consents to for the user.
2. Bank doesn't support several consents.

Here I'd propose to define several strategies: REPLACE, REUSE, USE_MORE_GENERAL, REPLACE_IF_NECESSARY, CREATE_SEVERAL.

• Replace means that the consent will be forced to replace with a new one.
• Reuse means that we shall use the existing consent. If it is not applicable for actual request we return error.
• Use more general - means - we create use existing consent only if it is more general. Or replace it with dedicated consent (means reuse)
• Replace if necessary - we use existing consent if it is applicable or replace it with more general.
• Create several - means that bank supports several consents for the user.

These strategies we'd need to save in bank profile for each bank.

In the future, we can also allow Fintech to provide its wishes for that with some header. This will be decided by us, we can follow the wish but if not possible (i.e. previous Consent was granted by another Fintech) we'll decide ourselves.

[nitch2019]

Still need to be decided depending on customer feedback