The equivalency approach means that each API Provider will set their own levels of customer authority based on their existing (or new) practices and precedents. The ‘illustrative examples’ below highlight the range of open banking scenarios that each API Provider will need to consider. Some of the scenarios set out in the ‘illustrative examples’ below may not be widely experienced or understood yet by customers. It will be important, both from a legal and customer experience perspective, for each customer (signatory and/or account holder) to be clearly informed of their own level of authority, and how all authorities apply over an account.
Informing customers of levels of authority would ideally occur at several levels (as applicable), including:
Terms and Conditions
Account operating authorities
Customer consent management processes
Contents
3.1 Illustrative examples of the Equivalency Principle
The following are illustrative examples only of how the Equivalency Principle might work across a range of scenarios. They are not guidelines or standards. The nature of the Equivalency Principle is that it aligns managing the scenario to each API Provider’s current practice - these practices may vary.
3.1.1 Authorisation
1. Authorising data sharing:
Joint accounts & accounts with more than one signatory: If one joint account holder or signatory’s account operating authority allows them to operate[1] the account, an equivalent practice could be allowing that account holder/signatory to authorise the consent to share account information with a Third Party.[2]
View only access: If one joint account holder or signatory’s has view only access over an account, an equivalent practice could be not allowing that account holder/signatory to authorise any consent to share account information data with a Third Party, as their view only permissions do not allow actions to be authorised authorisation of actions on the account.
2. Authorising payments:
Joint accounts: If joint account holders’ account operating authority allows them to individually authorise payments, the equivalency principle would also allow either to individually authorise payments from their joint account initiated via a Third Party. Conversely, if an Account Operating Authority requires more than joint account one account holder to authorise a payment, then the equivalent practice is that the same number of joint account holders would have to authorise the payment via a Third Party.[3]
3. Personal information:
Joint accounts: If the account information access request is for the ‘party’ resource to obtain personal information (name, date of birth, contact information etc) of all joint account holders, the ability of one account holder to authorise the release of other account holder’s personal information would be equivalent to what that account holder can access and download online, subject to their API Provider privacy policy and terms and conditions.[4]
More than one signatory on an account: If the account information access request is for the ‘party’ resource to obtain personal information (name, date of birth, contact information etc) of the account holder, and the signatory is not the person that the ‘party’ information relates to, the ability of that signatory to authorise the release of the ‘party’ information would be equivalent to what that signatory can access and download online, subject to their API Provider privacy policy and terms and conditions.
Notes:
[2] Note: This is supported by all versions of the API Centre’s Account Information API Standard.
[3] Note: Single payment authorisation is supported by all Payments Initiation API Standards. Multi-authorisation of payments will be supported by v3.0 of the Payments Initiation standard.
[4] Note: A single signatory authorising the data sharing of the ‘party’ information is supported by all versions of the API Centre’s Account Information API Standard. The API Standards do not support more than one signatory authorising the data sharing of the ‘party’ information as this is not considered necessary as there are no equivalent practices for this to develop standards against.