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 the account, an equivalent practice could be allowing that account holder/signatory to authorise the consent to share account information with a Third Party[1].
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. [2]
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.[3]
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.
3.1.2 Informing other account holders
4. Informing joint account holders of data sharing:
Joint accounts: If the account operating authority allows one joint account holder to authorise consent for a Third Party to access account information, the API Provider will follow their current practice and customer terms and conditions to guide if they need to inform other account holders whose data is also shared.[4]
5. Informing signatories of payments:
Joint accounts & accounts with more than one signatory: If the account operating authority allows one joint account holder or signatories to authorises a payment initiated via a Third Party, the API Provider will follow their current and future practices, and customer terms and conditions to guide if they need to inform the other account holders or signatories that a payment has occurred [5] [6].
6. Informing signatories of the revoking of a consent
Joint accounts & accounts with more than one signatory: If the account operating authority allows one signatory to revoke an account information access and/or an enduring payment consent, the API Provider will follow their current and future practices and customer terms and conditions to guide if they need to inform other account holders or signatories of that consent being revoked.
3.1.3 Viewing consents
7. Viewing consents on an account:
Joint accounts & accounts with more than one signatory: If their account operating authority allows one joint account holder or signatory to access and view an account, an API Provider will follow their current and future practices and customer terms and conditions. By way of example, an API Provider’s equivalent practice might be allowing that account holder or signatory to view any active account information consent or enduring payment consent on that account, including those they did not authorise.[7]
8. Viewing consents over multiple accounts:
Joint accounts: If one account information access consent covers multiple accounts including a mixture of joint and non-joint accounts was authorised by an account holder in line with their account operating authority, an API Provider will follow their current and future practices and customer terms and conditions. By way of example, an API Provider’s equivalent practice might be to allow the other joint account holders to only view that consent as being active over just the joint accounts that they have the authority to access (and not view the consent over the other account holder’s non-joint accounts).[8]
More than one signatory on an account: If one account information access consent covers multiple accounts, API Provider will follow their current and future practices and customer terms and conditions. By way of example, an API Provider’s equivalent practice might be to allow the signatory to view that consent as being active over just the accounts that they have the authority to access (and not view the consent over the other account accounts that they do not have access to).[9]
3.1.4 Managing consents
9. Joint accounts & accounts with more than one signatory:
If one joint account holder or signatory, in line with their account operating authority, can authorise the consent to share account information with a Third Party and/or authorise the establishment of an enduring payment consent, an API Provider will follow their current and future practices and customer terms and conditions. By way of example, an API Provider’s equivalent practice might be allowing that account holder to revoke consents, even if they were not the account holder/signatory that originally authorised the consent.
10. Joint accounts:
If one account information access consent covers multiple accounts including a mixture of joint and non-joint accounts, API Provider will follow their current and future practices and customer terms and conditions. By way of example, an API Provider’s equivalent practice might allow the other joint account holder to revoke consents that they have the authority to access (and not revoke the consent over other accounts that they do not have access to).[10] [11]
11. Joint accounts & accounts with more than one signatory:
If one joint account holder/signatory previously authorised a consent for account information access and/or an enduring payment consent, and that account holder/signatory subsequently either stopped being a joint account holder or had their account operating authority changed so they no longer have operating authority over that account, an equivalent practice could be the API Provider applying their same practice as they would with other similar consent scenarios. [12]
12. Joint accounts & accounts with more than one signatory:
If an account has been suspended or frozen by the API Provider, an equivalent practice would likely see payments initiated from that account blocked. With respect to account information access, an equivalent practice could be that if the account holder(s) / signatories still have view access on the frozen or suspended account online, then account information data sharing to Third Parties can still occur.
3.1.5 Footnotes
[1] Note: This is supported by all versions of the API Centre’s Account Information API Standard.
[2] 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.
[3] 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.
[4] Note: There are no industry standards for informing other joint account holders as this is covered by the equivalency principle. However, the API Centre encourages the development of consent management dashboards so that all account holders can view current data sharing consents.
[5] Note: Account holders may also be able to set up alerts to advise them of payments from their accounts.
[6] Note: There are no industry standards for informing other joint account holders/signatories as this is covered by the equivalency principle.
[7] Note: There are no industry standards for viewing consents. However, the API Centre encourages the development of consent management dashboards so that all account holders / signatories can view current data sharing consents.
[8] Note: This is a likely to be an obligation under the Privacy Act anyway.
[9] Note: This is a likely to be an obligation under the Privacy Act anyway.