Specify if an Account is a joint account in the API response

[frollo-cdr]

Description

To include whether an account is a joint account in the Get Accounts API response. The type of account is key information in many use cases, especially lending.

Previously this has been looked upon as a privacy concern particularly from domestic violence advocates.

Yet who the account holders are is a factual matter often shared by account holders.

CDR provides the means for consumers to get data about themselves but not about another joint account holder. This however is not about obtaining customer data for someone else but account data. Customer data and Account data are different and account name is in the account data. The type of account should not be a privacy concern.

This proposal is simply to expose the type of account, not the other party's information.

Area Affected

• Get Accounts API
• Get Account Details API

Change Proposed

Adding an additional property to the accounts response specifying if the account is a joint account or not.

DSB Proposed Solution

The current DSB proposal for this issue is in this comment.

[AdatreeCDR]

Adatree supports this change request. In our opinion privacy is not an issue as no details about the other account holder are being disclosed. If you look at the marketing for joint accounts by the banking sector, you would be led to believe that a joint account is in fact a different account type or, at the very least an account attribute. Private information that can be derived about the second account holder would more likely come from transactions analysis rather than a boolean that says the account is jointly held. If that kind of risk is not a concern then a joint account flag certainly should not be.

[RobHale-Truelayer]

TrueLayer also supports this change. As already mentioned by @frollo-cdr and @Adatree, there would not appear to be any material disclosure or privacy impact as a consequence. In fact, the opposite could be argued. If there is some concern over sensitivity, then this could actually be “coded in” to any workflow to protect vulnerable consumers given awareness of a JA scenario.

If the flagging of an account as a JA is still a concern, another option might be to state where the inverse is true - ie the account is “wholly owned by an individual”. Perhaps the flag should specify the type of account - single joint unspecified to accommodate those DHs not yet publishing this data.

There is actually some overlap with an existing (broader) request proposed by TrueLayer in February (https://github.com/ConsumerDataStandardsAustralia/standards-maintenance/issues/463) - to obtain account holder names. It might help to consider both suggestions collectively.

However, just focussing on this new issue, and the benefits of including a JA flag There would be some significant benefits to CDR use cases, perhaps most notably for lending.

• We know from previous research conducted during the JAMS->DOMS shift that 81% of home loans involve a joint account so these types of accounts are likely to be present when looking at mortgages.
• If data is being shared by an applicant as part of a loan application, if the JA flag exists, this will make it apparent that there are other parties who need to be considered in the loan contract.
• Perhaps the most significant benefit is with automated expense assessment - ie knowing that the expenses relate to more than one person. This will likely result in a more favourable outcome for the consumer.
• Logic in the assessment workflow can ensure that expenses aren't double-counted if two loan applicants both share the same account - this is critical when determining loan serviceability.
• Being aware of all parties on an account is also necessary when creating legal documents.
• Different questions and approvals are required if dealing with a JA loan application - multiple signatories etc
• The consumer / applicant may not be aware of implications of JAs so flagging this early could save time for them later
• Some switching use cases could also be better informed by knowing if accounts are JAs
• A better CX could also be provided by ADRs who could point consumers to their bank’s DOMS service to change settings on the JA if they wished to / needed to.

[ghost]

This addition would be very beneficial for a variety of ADR use-cases as already outlined. We support the request and see it as an worthy improvement.

Acknowledging that all DH's are different, from our DH position we don't see it as a challenging attribute to add.

Looking forward to this one being adopted!

[NationalAustraliaBank]

NAB also supports this information to be shared with the ADRs.

[CDR-API-Stream]

Hi all, thanks for the feedback on this. Treasury and the OAIC have confirmed that inclusion of a JA flag is permitted by the Rules. They have stated that additional personal JA data is not shareable (see below).

Customer data (which is information that identifies or is about the person, such as their first and last name) held about other account holders is not shareable under the CDR rules.

Under Schedule 3 cl 3.2(3) and Schedule 4 cl 3.2(4), customer data is neither ‘required consumer data’ nor ‘voluntary consumer data’ if it is in relation to an account holder or secondary user other than the person who is the subject of the request. This means that the Data Holder cannot disclose customer data about other account holders, and standards cannot be made to require this.

Other relevant provisions in the CDR rules include the restriction on accredited data recipients on asking for a consent for the purpose of identifying a person other than the CDR consumer that made the request (rule 4.12), and the data minimisation principle which provides that an accredited data recipient must not seek to collect more CDR data than is reasonably need to provide the goods or services requested (rule 1.8).

Whilst the CR focuses on joint accounts, can participants indicate whether this use case is also applicable to other multi-party accounts for individual and non-individual consumers?

[jimbasiq]

In the first MI 13 meeting we discussed what other data attributes we would like added to CDR APIs schemas. We have a few below:

1. Date of Birth for the individual who is consenting to the data share - customer detail
2. Running balance - transaction detail
3. Enum to flag if an account is accessible by more than one individual - account detail

[markverstege]

This item was discussed last week in the maintenance iteration. The outcomes of that discussion were:

• Introduce an enumerated field with SOLE_OWNER, JOINT_ACCOUNT, MULTI_PARTY values to the Banking Get Account and Get Account Details APIs
• The definition of "sole account", "joint account" and "multi-party account" are left to the discretion of each data holder
• Detailed party relationship information is out of scope for this change request and will be considered in the broader context of a Party Relationship API

Feedback is sought on:

1. Is the list of enumerated field types in line with ADR use cases, or are there other account relationships that should be included?
2. Should this be applied to both individual and non-individual consumer accounts?

[markverstege]

Hi @jimbasiq, thanks for the feedback.

1. Date of Birth for the individual who is consenting to the data share - customer detail

This is not currently permitted by the rules. See Schedule 3, section 1.3 (1)(c) (page 151): "(c) if the person is an individual―does not include the person’s date of birth."

2. Running balance - transaction detail

Could you please raise a separate change request for this to it can be consulted on?

3. Enum to flag if an account is accessible by more than one individual - account detail

Can you please describe how you see this differentiating from the enum being consulted on to handle sole, joint and multi-party account type?

[speedyps]

As stated in the call (26/10/2022), the preference from SISS would be that if we are using an enumeration, we would like some clear definitions such as SOLE=1, JOINT=2, MULTI=3 or more.

[NationalAustraliaBank]

We see, this is one of the 6 decision proposal which DSB will be opening. NAB will be taking that opportunity to respond to this request.

Meanwhile, our recommendation in brief at this point for the Joint Account Flag is -

1. The customer type "ORG" may always have multiple nominated reps and thus should be considered as having "Multi-Party". The determination of whether a customer is an "Individual" or an "ORG" can be done by calling GET Customer Details, for which the ADRs in whose use case this information is relevant should request for the relevant scopes at the time of Consent Creation
2. For an Individual customer, this field should be added with the enums as "SINGLE" and "MULTIPLE"

[anzbankau]

The proposed standards below are based on the following points (many which were expressed in the MI call 26/10/22).

1. The original proposal was ‘whether an account is a joint account’ i.e. the type of the account is joint.
2. The use cases in this proposal, its comments and the MI pertain to lending and different processing paths, with switching being another.
3. The emphasis is on ‘ownership’ of the account i.e. a role that reflects a degree of control over that account.
4. Ownership of accounts of non-individuals is significantly more complex than for those of individuals and joint accounts are not applicable to non-individuals.

Note: While ONE and TWO may be awkward being numbers, DOUBLE (to pair with SINGLE) is also awkward. And in the context of an 'account type', SOLE evokes 'sole owner' and would need to be paired with JOINT, which has a broader meaning in CDR as discussed in the MI.

Proposed Standards

---

Field	Optionality	Description
ACCOUNT_OWNERS	Optional	The number of parties with an ownership role on the account. This may influence how the account is treated e.g. a lender may need additional information from the other party(s) or may be reluctant to consider the account an asset when more than two parties are owners of the account. Not to be used for accounts owned by organisations.

---

Enumeration	Description
ONE	A single party has an ownership role on the account.
TWO	Two parties have ownership roles on the account. For example, a joint account.
MANY	More than two parties have ownership roles on the account.

---

[markverstege]

Hi @anzbankau, thanks for offering a proposal. Based on the discussion in the last MI call, the proposal would apply for both individual and non-individual accounts. It is at the discretion of the Data Holder how to treat the account ownership for organisations. It was noted by some data holders that they do permit multi-owner non-individual accounts. For instance, some sole trader accounts may be treated as non-individual consumer accounts that could have two or more account owners.

Further to this, we don't currently have a concept in the account APIs of individual vs non-individual account. If we adopt the change with the optional account ownership field plus the exclusion for non-individual consumers we couldn't default it as having the field absent would mean that the account isn't a personal account.

[CDR-API-Stream]

The current proposed solution is to adopt the change as proposed by @anzbankau here without the exclusion for organisations and the change listed below. That is, this change would apply for both individual and non-individual consumers.

It's proposed that the field be named accountOwnership with description "The number of parties with an ownership role on the account."

[markverstege]

Hi @NationalAustraliaBank thanks for the feedback.

We see, this is one of the 6 decision proposal which DSB will be opening. NAB will be taking that opportunity to respond to this request.

One minor correction, we discussed a Decision Proposal for a more extensive party relationship API but not for this change. This change can continue as a change request to deal with a more simple account ownership flag on the account.

Meanwhile, our recommendation in brief at this point for the Joint Account Flag is -

1. The customer type "ORG" may always have multiple nominated reps and thus should be considered as having "Multi-Party". The determination of whether a customer is an "Individual" or an "ORG" can be done by calling GET Customer Details, for which the ADRs in whose use case this information is relevant should request for the relevant scopes at the time of Consent Creation

Thanks. This change is not to be confused with nominate representatives. The change relates to the number of parties with account ownership. For non-individual consumers, a nominated representative relates to the authenticated end user who has the authority to establish data sharing access on their behalf. However this change considers how many parties have ownership of the account. Whilst and account owner may be a nominated representative, that is not always true and the two concepts should be treated separately.

Definitely correct, if the ADR needs to know whether the consumer is an individual or non-individual, they would need to request the customer scope under the current data clusters.

2. For an Individual customer, this field should be added with the enums as "SINGLE" and "MULTIPLE"

Thanks. As noted, @anzbankau have offered a proposal which aligns to this and the discussion of a two-party account ownership being distinct from three or more (multi-party) and decoupling terminology of account ownership from the overloaded "sole" and "joint" definitions.

[CDR-API-Stream]

Based on the discussions in the maintenance iteration, it was agreed that the DSB would post the proposal and incorporate provisions for complex ownership relationships. More commonly this will apply for non-individual consumer accounts e.g. a business, but there may exist complex ownership relationships for individual consumers as well e.g. probate scenarios for individual accounts.

DSB Proposed Solution

This change will introduce a new accountOwnership field into the BankingAccount object and apply to both the Get Accounts API and Get Account Details API. This change is a breaking change and would require a future dated obligation date. Further, the breaking change would introduce an increase in the version for the affected APIs:

• Get Accounts API v2 (currently v1)
• Get Account Details API v3 (currently v2)

It is proposed that the change aligns to a 6 month implementation milestone. According to the obligation schedule the corresponding obligation date would be: Y23 # 3, 10/07/2023.

Feedback is welcomed on the obligation date. It may be beneficial where other changes are identified for the affected APIs for them to be bundled together in a single release.

Details Name	Type	Required	Description
accountOwnership	string	mandatory	Value indicating the number of customers that have ownership of the account, according to the data holder's definition of account ownership. Does not indicate that all account owners are eligible consumers.

Enumerated values Property	Value	Description
accountOwnership	UNKNOWN	The exact party relationship cannot be determined.
accountOwnership	ONE_PARTY	One party is the owner of the account.
accountOwnership	TWO_PARTY	Two parties are the owners of the account.
accountOwnership	MANY_PARTY	Three or more parties are the owners of the account.
accountOwnership	OTHER	The account ownership relationship is a complex arrangement that cannot be expressed by the number of owning parties.

[frollo-cdr]

We are supportive of the DSB's proposed solution above as it fulfils the original change request.

[WestpacOpenBanking]

Westpac supports the need for a Joint-Account flag, however does not support the proposed solution for the AccountOwnership field. Leaving the definition of the proposed values to the discretion of each data-holder will introduce variability into the ecosystem that reduces the quality and reliability of this field when consumed. Adhoc introduction of attributes into a sectors compliance could result in a patch work of changes that bring minimal consumer value and overlook longer term privacy and data minimisation concerns. Westpac proposes that different options be proposed and consulted via a Decision Paper, so that a better outcome can be achieved for the ecosystem. We would also like this item to be tabled into the agenda in the next Data Standards Advisory Committee scheduled for 14-Dec.

[NationalAustraliaBank]

We agree to the comments by Westpac.

The introduction of accountOwnership field proposed above, will reduce the stability of overall solution and also potentially increase the response time. To achieve the balance points between the extra business value and cost/time required to support this proposal. We support the new flag for accountOwnership as suggested by Westpac.

[CDR-API-Stream]

During the maintenance iteration a variety of options were canvassed and discussed and each represented a trade off between the functionality being requested by ADRs and cost/time of implementation for DHs. The DSB believe that the proposed option is a reasonable compromise between competing needs and that further consultation would be unlikely to result in a different outcome.

It is also noted that the values represented in the enumeration must already be determined to meet the rule requirements for supporting a Joint Account Management Service and Complex Accounts.

As a result we will be proceeding to recommend the proposal as presented at the final MI meeting.

[nils-work]

This change request was incorporated through https://github.com/ConsumerDataStandardsAustralia/standards/issues/272#issuecomment-1362187373