...
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.
...
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.
...
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.[1]
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 [2] [3].
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.
...
Notes:
[1] 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.
[2] Note: Account holders may also be able to set up alerts to advise them of payments from their accounts.
[3] Note: There are no industry standards for informing other joint account holders/signatories as this is covered by the equivalency principle.
...
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.[1]
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).[2]
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).[3]
...
Notes:
[1] 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.
[2] Note: This is a likely to be an obligation under the Privacy Act anyway.
[3] Note: This is a likely to be an obligation under the Privacy Act anyway.
...
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)[1].[2]
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.[3]
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.
...
Notes:
[1] The Account Information standard’s ‘selected accounts’ section refers to changes to the set of accounts, for example one of the accounts covered by the consent is closed, or the customer adds to the group of the selected accounts. The standard, in summary, says that subsequent changes to the set of accounts to which the authorisation applies may be carried out directly with the API Provider, and that the method for doing this lies in the competitive space. There is no requirement in the Standard to be able to support the functionality described in this scenario, but this functionality is recognised in the standard and left to each API Provider’s implementation.
[2] Practices in this scenario, that are not covered in the standard, are expected to evolve as lessons are learned from implementations and initial experiences.
[3] Note: A common practice would be to leave the consent in place as it was appropriately authorised at the time of establishing it, and this could be consistent with managing direct debits or automatic payments. However, this may not always be the case as in an API Provider may wish to take steps to reconfirm the standing of the consent. Also note that the API Standards include API Providers being able to escalate and request a re-authorisation (or similar) from the customer.