Decision Proposal 026 - Customer Payloads

[JamesMBligh]

This decision proposal outlines a recommendation for payloads of the Customer end points.

Feedback is now open for this proposal. Feedback is planned to be closed on the 19th October. Due to the complexity of the data payloads, a revised version will be published around the 13th October incorporating feedback received to that date.
Decision Proposal 026 - Customer Payloads.pdf

[RalphBragg]

It is great too see Customer Identity Information being included in the standards, Customer Identity Information is often regarded as the missing link or holy grail of API ecosystems yet I note that there is nothing in this payload that provides information that would allow a consumer to utilise the information to "onboard" or convert a customer. i.e Information on when Identity Claims about an invidual or an organisation have been verified or vetted nor what form of primary document was provided to confirm these claims.

Additionally, Identity Information and the surity off is not just a data problem but also a credentials management issue. Can the consumer be assured that the individual that owns the identity resources is in fact the individual that was using the credentials? How can a relying party be sure that it is "the customer that has authorised the session"?

How the session was authenticated and therefor the level of trust that a relying party can have that it's customer, is in fact the bank's customer, is very important and currently not included in the payload. As this information pertains to the session and not the resources themselves, it's may be difficult for a bank to provide this information via a resource endpoint or service that's not designged for this service.

The title of the API Specifications, "Obtain basic information on the customer that has authorised the current session" implies to a relying party that it is always the owner of the resources that is in charge of the credentials, with serializable credentials still the norm this isn't a statement that can be reliable made. In reality, it will be the whomever holds the credentials at the time the authorization was given but it may not necessarily be the customer. Has consideration been given for multi authorization steps or when multiple individuals are named on the account? i.e joint accounts. The proposed payload does not appear to be an array of persons.

These are common identity problems / challenges that have been tackled by the identity community firstly by the introduction of OpenID Connect to add the "Identity Layer" to the internet. An Identity Claimset would work very well should FAPI R or FAPI RW be adopted as the security solution. Torsten Lodderstedt has proposed an identities claims set that tackles a lot of the issues that i've raised here which Open Banking UK will be looking shortly.

The upcoming Vectors of Trust Framework https://tools.ietf.org/html/draft-richer-vectors-of-trust-15 should be considered as well as it provides a standard means of conveying not just the level of assurance that a provider has in the identity being provided but also the means that the identity was asserted i.e the credentials. A vectors of trust claim could be used as part of the "session information" provided during the authentication experience.

If there is no intention to "back door" identity services into Banks then this should be made clear that TPP's should not utilise this information for identity / AML / KYC purposes in which case the information significantly reduces in value for relying parties. If the intention is for Banks to provided identity services by surfacing this information then it would make sense to ensure that the appropriate internet identity standards and technologies are utilised.

Ralph Bragg
Raidiam Senior Partner
OBIE UK - Ecosystem Security and Trust Framework Architect
Open ID Foundation FAPI WG

[speedyps]

Question on addresses, sometimes there is the concept of physical address, mailing address and registered address. The specification as proposed forces there to only be two addresses, would it not be better to follow the pattern as proposed for Phone Numbers or Email Addresses?

[JamesMBligh]

@RalphBragg, thanks for your detailed comments. The ACCC have indicated that KYC information will not be included for MVP and we addressed the potential for a limited form of assurance in a previous decision.

This will likely be an issue that gets addressed in the future.

[RalphBragg]

No worries @JamesMBligh this specification is very similiar to the OBIE UK Party Endpoint https://openbanking.atlassian.net/wiki/spaces/DZ/pages/645203403/Party+v3.0

GET /accounts/{AccountId}/party
If the ASPSP has chosen to implement the /accounts/{AccountId}/party endpoint - the ASPSP must return details on the account owner:
In the case of a joint account - this will be the party that has given authorisation to the AISP to view the account. If the AISP wishes to access details of other parties linked to the AccountId, the AISP must go through an authorisation flow with the other parties.

This means that the resource returned, potentially for the same account / resource endpoint, will be different depending on the session that is authenticated. Given the desire to essentially provide identity claims about the logged in user, providing this information via OpenID Connect's userinfo endpoint (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) would be more standards compliant. It would also provide a means of providing information about the session (credential type used).

The use of standard OIDC identity claims functionality provides out of the box support that would allow individuals greater control over what exactly they share when it comes to personal information via a mechanism that is well understood by TPPs, ASPSPs and Consumers. It also unlocks / futureproofs a lot of capability for all participants.

Of course this is dependent on an OIDC backed security profile selected.

Cheers,
RB

[speedyps]

Under Section 8 - Consent of the ACCC Consumer Data Right Rules Framework, there is provision for where consumers, with a joint account, have individual authority to take action. The customer model above will work for this, but not if dual authorisation is required.

The model used today by the major accounting solution providers (TPPs) to get data when dual authorisation is required currently supports dual authentication.

For example, I am the Owner of a small business employing 15 people. I have an in-house bookkeeper who is authorised to setup things like payments, transfer money, or to fill out the form (or configure within the banking portal) the authorisation of data to go to a TPP. However, the book-keeper is not able to solely approve the authorisation (or may not be able to approve at all). I have a GM and a personal assistant (PA) who, along with myself (the owner), are authorised to approve things the book-keeper does. Any approval requires two of the authorisers to approve. I have specifically requested this to be set up.

In the case of filling out the form to get data, the book-keeper then takes it to any two of the authorisers to get them to sign the form. The form goes off to the ASPSP, and if the signatures are correct, the connection is authorised - until cancelled.

If the approval is via internet banking, then two of the approvers have to sign in to authorise the connection, again until cancelled.

Under CDR, using the model where the account-request is submitted, when a user signs into the ASPSP to approve, then the normal rules of the ASPSP could be applied. In the case of the example above, the book-keeper would then get two of the authorisers to approve, and request would be completed.

If the customer payload presented allowed for Person to be multiple, and allowed for the role of the person in the process to be included, then it could show the book-keeper - as requestor, and then two approvers as authorisers.

The one issue that remains, which most likely makes it necessary to create a special exception for CDR for more than one authorisers, is to do with the time bound reauthorisation. In the above example, after 90 days is up, is the book-keeper would have to trigger the reauthorise process, and have two of the approvers authorise again to allow data to continue to flow to the TPP.

A couple of extra questions:

• Does reauthorisation update this customer record or create a new one?
• Does the same Person have to reauthorise? In the case of business accounts, this may not be practical.
• Should the system allow retrieval of the authorisation history? I may want to know which people over time have authorised this.

[bazzat]

The ABA Open Banking Technical WG has a few initial observations/questions, posted here in the hope they'll be useful in producing the revised version:

• Should address have a more granular structure?  Simple concatenated strings are a good lowest common denominator but would it be sensible to provide an optional, more granular structure (e.g. including fields for street number, street type etc.)?
• Will fields like addressLine1 have a specified maximum length?
• As a general rule it is inadvisable to make most customer detail fields mandatory, as customers do not always provide all information.
• This address structure doesn't appear to allow for international customers. Country can be specified but there's no allowance for capturing an address in the format for the destination country. Would it be sensible to explicitly comply with Aust. Post addressing standards?
• It’s not clear whether or not it is currently universal standard practice to use the ANZCO Standard Classification of Occupations. For those banks that don’t already use this classification there will be a significant amount of work required to map to it.
• organisation may be including too much information in Basic. Members have suggested that organisation be limited to businessName and legalName in Basic Customer Data.
• abn is mandatory - What about international organisations?
• When external standards are referenced the version number needs to be specified. For instance it is incorrect to assume that everyone is using the latest version of ANZSIC e.g. ANZSIC 2006 vs. ANZSIC 1998.
• establishmentDate needs more of description. The precise intended meaning is not necessarily obvious.
• Mobile phone numbers are often used for 2FA. Should they be masked (or excluded)?
• Should there be the option of providing an extension number with a phone number?
• PositiveIntegers in phoneNumbers - wrong type? Leading zeroes will be lost.
• Not everyone captures purpose on emailAddresses.
• From a Security standpoint, some of the data outlined for sharing as part of the customer payload could increase the risk of identity theft. For example, data such as mobile number and DOB are frequently used for the purposes of password recovery and multi-factor authentication. Data used to verify customer's identity should not be shared. DOB definitely should NOT be included in the basic payload.
• There may be value in including a field to capture the last date/time of capture of business information. This data can fall a long way out of date and businesses may not have the option of updating their details online. Arguably the date/time of update would help identify potentially unreliable data.

[WestpacOpenBanking]

Westpac has the following preliminary feedback in relation to the proposal. We are likely to provide additional feedback and address the questions posed by Data61 after the revised proposal is published. Points:

• Customers do not always tell us when records become out of date. A field indicating the last updated time for the person and organization records would be wise.

• Versions of AS 4590.1. Interchange of client information and AS 4819 Rural and urban addressing are standards that have been published in relation to customer information and addresses in Australia. Institutions are likely to have considered these in choosing how to collect information. Certain details may also need to be collected because of regulations relating to business, taxation and/or identity verification. These sources may be good points of reference as the standard evolves, especially in the context of use cases like fast switching or pre-filling of applications.

• In relation to person:

  • Names:

    • There are people with only one name. Guidance is required here to avoid inconsistency between providers and allow e.g. correct initialisations.
    • The correct ordering of names for addressing a person may depend on language and culture.
    • It’s feasible that middle names will not always be all captured by intuitions.
    • The standard needs to be prescriptive for prefixes and suffixes in terms of formatting or inconsistency will occur between institutions. The fields should either be optional or allow the empty string as a response for cases where no prefix is known.
    • Which version of ANZSCO for occupationCode? What is the interpretation where the code is not given in a response, is it “unemployed” or “unknown”?

  • Phone Numbers:

    • The minimum length of the phoneNumbers Array[Object] is not specified. Is it intended that an empty array is a valid response?
    • What additional value is provided by having both fullNumber and component fields? Is the aim to improve consistency without failing to account for edge cases missed by a regular expression for fullNumber? It may be non-trivial for some institutions to parse and split full numbers if the components are not known.
    • Extension numbers and other details could be appended to phone numbers. These may not be delimited consistently or stored separately in legacy records. Should these details be appended to fullNumber and number?
    • The fields countryCode, areaCode and number may all begin with zero – the PositiveInteger type is unsuitable because e.g. 0123456789 and 123456789 are the same positive integer.
    • Perhaps countryCode should be prefixed with “+” (so that the default is e.g. +61)? The + is a placeholder for country specific dialling prefixes (usually 0011 in Australia).
    • Should areaCode include the 0 prefix for Australian numbers? Normally it is not included if the country code and prefix placeholder is included.
    • It’s feasible that stored phone numbers could have extension numbers and that these may not be positively identified as such in institutions systems.
    • isPreferred is either True and present or False and not present. There may be arguments to have it present in both cases. It’s also feasible that there are intuitions that would not capture preferences. Default preference may also depend on the time of day and an ordering of preferences may be captured in some circumstances. Which number is “preferred” in those cases?
    • The purpose field description should clarify that the number is as indicated by the customer (as opposed to as inferred from the number). An additional “UNKNOWN” type might be useful to indicate this situation.

  • Email Addresses:

    • An additional “UNKNOWN” type for email addresses is needed for the case where an institution does not capture the purpose.
    • (as for phoneNumbers) The minimum length of the emailAddresses Array[Object] is not specified. Is it intended that an empty array is a valid response?
    • (similar to phoneNumbers) isPreferred is either True and present or False and not present. There may be arguments to have it present in both cases. As email is an asynchronous communication medium it may be less likely that preferences are captured or that preferences depend on the time of day. Some institutions may have a preference ordering. Which email address is “preferred” in those cases?
    • It may be prudent to reference the appropriate RFCs for correctly formatted email addresses or otherwise provide a regular expression.
    • An email address may be known to be invalid. What is the expected behaviour in that case?

• In relation to organisation:

  • The organisationType field may not be aligned with similar details included as part of an AMLCTF identity verification process for business. Closer alignment may support Open Banking use cases like form pre-fill or fast switching.
  • establishmentDate is ambiguous without a description.

• In relation to the Address Type:

  • The mailingName field from organisation may be better placed as a property or as properties of the Address type.
  • For some institutions addresses may be associated with accounts rather than the customer. Which address should be returned in this case? Does it vary depending on the consent given? Some or all of these accounts may no longer be active or open.
  • The pattern for providing addresses in the response isn’t consistent with the array[Object] approach used for Phone Numbers and Email addresses.
  • Similar to email addresses, an address may be known to be invalid. What is the expected behaviour in that case including with regard to preferences?

[commbankoss]

CBA's position on the customer payload proposal is that it is not in line with the position in the ACCC rules framework that KYC data should be excluded. As a principle, we believe it is necessary to minimise the personal identifiable information on customers to safeguard privacy and security. In our view, the proposed customer payload fields include unnecessary personally identifiable data for both business & personal accounts (e.g. full address, ABN). 
 
Given that not all data recipients are subject to equivalent KYC/AML auditing processes or equivalent fraud & security controls as the banking sector, exposing personal identifiable information data opens up risk for customers if a data breaches occur, potentially resulting in Identity Take-Over (IDTO). In all cases, the sharing of PII fields beyond requisite fields for account matching should not be mandatory and customers should have the ability to select which information they are willing to have shared.
 
We feel that a proposal in relation to complex authorisation and consent needs to be considered prior to the proposal on customer payloads. As stated above by @speedyps , we are concerned that not enough consideration has been given to the complexity of authorised operators on business accounts. We have a duty of care to protect customers from unintentional authorisation of data sharing without adequate consideration of roles and related rights to share. 
 
The proposed definition of a 'customer' also does not incorporate enough consideration for business customers as unique from consumers. Customer payload treatment for business entities needs to be separate from that of individuals. Having a business entity associated to a customer could have significant complications as there is no role associated to that person or any indication of who would have the authority to make decisions on behalf of that entity. Customer definition needs to include business which would have information (i.e., a 'person'). In addition, consideration needs to be how multiple business relationships are represented. This customer payload doesn't account for a 'customer' having associations with multiple entities (e.g., Company having subsidiaries).
 
In light of the above, CBA would not endorse this decision as the right implementation of a customer payload. Further consideration of the use cases for the information that would be provided at both customer basic/detailed payloads needs to be done. .

[JamesMBligh]

Wow. Thanks everyone, this is an awesome set of feedback. It's taken me a while to process it. Here are comments on the specific feedback:

Use of OIDC UserInfo
As articulated in the proposal the customer record is a critical record for the regime and is likely to be expanded over time. As this is a specific entity of value under this standard compliance with the OIDC standard is not a key goal. This is also an entity where there is likely to be sub-resources in the future and the possibility of reuse in other context. This is why the choice has been made to create a specific set of end points and payloads.

Additional Parties
Additional parties are only applicable in the context of a specific account and therefore would be a sub-resource of an account as has been done in the UK standards. Party has not be included in this standard yet due to the concerns around one party authorising the transfer of another party's personally identifiable information. If this is added in the future it will, however be added as to the account API set.

Authorisation vs Customer
I'm not sure I understood the concern around the creation of a record when a new authorisation is created @speedyps. This may be for the security stream but, as yet, there is no concept of multiple authorisations being created for a combination of data consumer, data provider and customer. A new authorisation would not create new data. The response provided for these end points would, however, be different depending on the context of the authorisation (ie. personal authorisation or authorisation as an agent of a business).

Mandatory vs Optional
ABA provided feedback: "As a general rule it is inadvisable to make most customer detail fields mandatory, as customers do not always provide all information". One of the principles for this regime is to require fields as being mandatory wherever possible. Rather than make all fields optional I would prefer specific feedback on which fields should be optional or in what circumstances.

SIC Codes
I'll add a version to the SIC spec (probably the latest)

Business Record

• Alignment of org type to AMLCTF - I believe this should be considered in a future revision when KYC information is incorporated. Even in that scenario it would still be useful to have two fields, one for the simple delineation of the four legal entity types in Australia and one for the more expansive information
• The role of person for a business - Good point, this should be added. I toyed with the idea of a person record and a business record incorporating agent. I will review if this preferred or if it would be better to add an agentRole field to the business record.
• establishmentDate needs description - Ok. I thought it was self explanatory
• Mandatory ABN - Without an ABN you can't establish a business bank account in Australia. This implies that an ABN being required is valid. As we address other industries we may revisit this and make it conditional

lastUpdated date
Good idea. I'll add it. Should it be optional? Mandatory would be preferred.

Names

• Single names - I'll add commentary on what to do for single names (probably put in surname field)
• Middle name optional - OK. Presumably first name optional also based on the above comment
• Prescriptive prefixes and suffixes - Is there a predefined standard for this? If not, rather than be prescriptive I'll insert commentary on formatting. Also, happy to make this optional

Addresses

• Mailing Name - I'll move this to address as an optional field and remove from the business record
• Multiple Address - Fair enough. I'll make it like phone numbers and email addresses (with a requirement of at least one record)
• Granularity - I wrestled with this a lot when creating the proposal. Specific fields are more useful but not all providers will have them available. A lower resolution like this is likely to be more implementable. In the end I opted for this model as there are now many online services that can decompose an address and most use cases don't require it anyway. I'm not keen on added to variants in the same payload where you might get the high granularity fields or might not. That seems a bit yukky.
• International Standard - Based on my research this format will suffice for international addresses. I could be wrong though - Is there something specific missing?
• Max Length for fields - This is more of a concern for an update or create end point. For read there is no advantage to a max length as all it will do is result in arbitrary truncation.

Phone Numbers

• Minimum Record Count - Yes, I assume it should require at least one record
• Mobile Phone - This is scenario where a customer has specifically asked for detailed data to be transferred. If it is masked then all that will happen is a customer will be asked to enter it anyway. I see no value in masking from this perspective. A customer should be able to tell other people there mobile number.
• Phone Extension - Good point. I'll add it
• Numbers as Strings - D'oh. Sorry, they should be strings
• Full Number - The purpose of full number was simply to provide a pre-composed full number that would be useful in certain contexts that would be built from the constituent parts. It was not that the full number would be decomposed into the other fields
• Require plus for Country Code - Good idea
• Area code should not include 0 - Good idea
• Unknown Purpose - Good idea, although I might add UNSPECIFIED to imply that it was customer choice rather than an implied purpose by the provider

Email Addresses

• Minimum Record Count - I assume that an empty array is valid for email but I'll be specific
• Unknown Purpose - Good idea. I'll do it the same way as phone number
• Email Address Specification - Good idea. I'll set it to the addr_spec portion of RFC 5322 unless there are concerns with this

Invalid Addresses
Not sure about this one as it implies a judgement call on the part of the provider as to whether the address (or email address) is valid or not. I would expect that invalid addresses would simply not be returned. I'm loather to be specific on this one without more feedback from the community.

Date Of Birth
Thanks. That's what I thought. I will leave it in the detailed payload.

We shouldn't include the customer record in scope
The decision not to include KYC inputs in the July 1st scope does not mean that personally identifiable information is not included at all. The data included in this payload could reasonably be considered part of a useful customer record for any industry, even those not requiring adherence to KYC principles and regulations. In addition, a plain reading of the designation instrument and ACCC rules framework both require the inclusion of this data.

There's a lot in here so I'll add the update later tonight.

-JB-

[JamesMBligh]

Please find attached version 2 of the proposal with feedback incorporated:
Decision Proposal 026 - Customer Payloads.pdf

-JB-

[jh-a]

@JamesMBligh - could you clarify for the uninitiated - is the intention in this resource to serve information regarding the 'customer who has authorised the current session' or in relation to information that sits on the account product?

There could be a potential conflict where an a customer has access to a range of accounts with different telephone numbers, addresses and the like. My sense is that there is a range of data in the proposal that doesn't apply uniquely to a customer identity, and whilst they might be connected to it, for the purposes of providing information on a customer, practically adds very little.

It would help if there was a stated intention behind the resource - the challenge a data consumer faces is linking the user they incept to ownership of a particular account. Unless the customer information is tied to an account this makes things difficult....

[JamesMBligh]

Hi @jh-a, yes these payloads and associated end points relate to the customer authorising (or more exactly the customer associated with the credential giving authorisation), not a specific account.

Account level contact and address information would be included in the detailed account payloads yet to be published. Account ownership would also be determined via the account end points, not this one.

-JB-

[da-banking]

state
This should be clarified as either the full state name, or an abbreviation, not both.

occupationCode
We do not have this data available in the ANZSCO coded format. Given that the field is optional, we could omit it. However we do have non-standard employment categories that could be returned if this field was free-text.

industryCode
We do not have this data available in the ANZSIC coded format and adding it would be expensive, recommend making this optional.

organisationType
It is unclear what this is intended to be used for. Organisations have a type, but the values are not an enumeration as such, they are configurable and support the business rules of the bank. It's unclear how these internal categories are meaningful to an outside entity, or what other values might exist among other CDR regulated industries, and it's therefore difficult to map these into an enumeration.

We could define some mapping rules like if contains "Trust" then "TRUST" but there are going to be others that we can't map into an enumeration. We would recommend that the use-case for this be clarified.

Without a clear use case, this field should either be:

• dropped entirely; or
• specified as free-text, with the data consumer interpreting the values not the data provider; or
• expanding the enumeration to also include more values such as ASSOCIATION, COOPERATIVE, GOVERNMENT_ENTITY; and adding an OTHER value as a catch-all.

purpose
For a phone number, this property has only one use case - to inform the data consumer of when they should use a particular phone number to contact the PSU. For example a WORK phone number would be preferred during business hours; a HOME phone number at other times; but a MOBILE phone number at all times.

INTERNATIONAL should not be in the purpose Enum at all for phone numbers - it is a different category of information, and can be inferred from the phone countryCode or fullNumber property. For example a MOBILE, WORK, or HOME phone number can also be INTERNATIONAL. We recommend INTERNATIONAL is removed.

Email is a different form of communication to phone, in that an email address is unattended, but a phone is not. The concept of the most convenient time (business hours, or non business hours) does not apply to email communications. We recommend that purpose is dropped on email addresses.

phoneNumbers.fullNumber
The inclusion of countryCode, areaCode, number and extension as separate properties duplicates information already defined in the fullNumber property, bloating the payload, and complicating the implementation, without a clear use-case. We recommend these properties are dropped, and that the standards focus on exposing the data and not interpreting the data.

We recommend that the format of fullNumber be made to conform with section RFC3966 - Global Numbers which already supports extension numbers. So the fullNumber "+61294905500;extension=1234" would capture the countryCode "+61", areaCode "02", number "94905500" and extension "1234". Parsing phone numbers in this format is a trivial matter if required by data consumers, and browsers and mobile phones can interact with numbers in this format with little to no modification.

[jh-a]

@JamesMBligh - thanks for the update. Given the the authenticated user resource is treated separately from the account resource, how are data consumers able to link an account resource payload to an authenticated user?

[speedyps]

@JamesMBligh

Authorisation vs Customer
I'm not sure I understood the concern around the creation of a record when a new authorisation is created @speedyps. This may be for the security stream but, as yet, there is no concept of multiple authorisations being created for a combination of data consumer, data provider and customer. A new authorisation would not create new data. The response provided for these end points would, however, be different depending on the context of the authorisation (ie. personal authorisation or authorisation as an agent of a business).

The case I have seen is that there are times in the Accounting Solution Provider (ASP) world, where an account may be attached to two Companies within an ASP's product. There are many reasons the consumer may do this (and they are not always logical to others).

My question is based on the fact that the ultimate arbitrator of if the authorisation is the data provider. There are possible risks if the data consumer has to handle the authorisation internally, when using the data provider to redo the authorisation would be the cleanest approach.

If the authorisation loop is gone through again, it will in theory, create a new authorisation on the data provider side. To keep things tidy, if the authorisation succeeds, the data consumer would update the authorisation on their side, and notify the data provider that the old authorisation is no longer valid. The data provider could then revoke the old authorisation

Another possible area where this case may appear, is where several data consumers are using a data aggregator to collect data on their behalf. This could result in a consumer or business authorising for one data consumer and then authorising for another one. Depending on how this is done, the data aggregator could have two valid authorisations.

[elsamarkula]

Feedback from the Australian Retail Credit Association (ARCA)
The Australian Retail Credit Association (ARCA) is the owner of the Australian Credit Reporting Data Standard (ACRDS). The ACRDS is the input data supply standard used for credit information. Its use is mandated via industry agreement (the Principles of Reciprocity and Data Exchange), and it is utilised (or in the process of being utilised) by a large number of credit providers (including those who are impacted by the first roll out of Open Banking).
Based on ARCA’s experience, a data standard ought to be designed to promote data consistency and quality, and in doing so, support the integrity of the system (whether credit reporting or, in this case, open banking). Simply drafting a standard to achieve a data transmission is not enough. Ideally, data should be inputted by all participants to the exchange in the same manner, and thus able to be consumed (particularly in an automated format) by those participants.
In this regard, address data can be particularly problematic if the standard for exchange is not sufficiently granular. It is recognised that organisations will have proprietary methods for recording and storing addresses, and this will vary across industries. A data standard which enables those organisations to retain those proprietary methods on data input simply “passes the problem” to the data recipient – insofar as the onus then falls to the data recipient to translate the address information into its own addressing standard. This can lead to issues locating customer information (where addresses do not match), and errors where correct information is deleted (simply because the recipient has taken a guess as to which address data is correct).
We appreciate the need to draft and implement a standard which enables the transmission of data by the July 2019 deadline. However, strong consideration ought to be given to the issues ARCA has highlighted, and particularly whether the outcome of developing a high-level data standard to meet this deadline, but which then leads to data inaccuracy issues (and subsequent consumer complaints to external dispute resolution schemes) is desirable.
ARCA’s more specific observations of the customer payload:
• Address should consider formatted and unformatted address constructs. A semi-formatted address is fine for mailing purposes or human use but not for automated processing purposes. Recommended consideration of Aust Post or PSMA G-NAF address structure and adopt that as the standard.
• Address types – support granularity in address data entry, given issues experienced in ACRDS. Should stipulate the order of address entry [See ACRDS formatted address list – Property Building Name, Unit Number, Street Number, Street Type, Suburb/Town, State, Postcode, DPID, Country], number of characters, and acceptable characters.
• Address types – note that use of ISO country codes is still in its infancy (ARCA is looking to enable this in the ACRDS, but not all credit providers have this capability).
• Address types – worth considering the option of enabling geo-locations to be used in future? (something ARCA is looking at in context of ACRDS)
• Name – any ability to allow previous names as well as current name? What if customer has legally changed their name, but account held in previous name?
• Date of birth – mandatory field – note that this may prove problematic. We understand a number of legacy accounts held with customers without DOB recorded (this still meets AML/CTF requirements).
• For identity info should consider provision of identifiers (if permitted) – Driver’s lic, TFN, Medicare number, Passport number.

[WestpacOpenBanking]

We support the proposal to the extent that we are able to comply. Data quality issues are common with customer information. For example, customers might accidentally transpose or misspell names. We suggest that the descriptions of person and organisation reflect this nature of how data has been collected. This would facilitate interpretation of the proposed Consumer Data Right Privacy Safeguard 11 in this context. Additionally:

• We agree that date of birth should be kept in the detailed message because of its sensitivity. We are concerned that the detail may be used be used by customers and other institutions in other contexts such as passwords, answers to secret questions or as part of identity verification processes.
• Not all organisations are registered with ASIC and have an ABN. We suggest that abn is optional for this reason.
• The Address type should follow Australia Post guidance allowing for 2 lines detailing the addressee or mailing name and 3 lines detailing the physical address. Westpac stores addresses in a manner compatible with this guidance. Further consideration may need to be given for international addresses.
• The lastUpdated field is valuable if indicates when the record was last updated by a customer, but not if it simply when a row in a database was last updated. We are not sure that all institutions would collect the former and so suggest the field is optional for that reason. Additionally, the field description should state that it is the effective date if the record has not been updated since creation.
• Individuals acting on behalf of an organisation may not wish for their personal details including date of birth or personal contact details to be disclosed.

[bazzat]

The ABA Open Banking Technical Working Group had a few, relatively minor, observations about the revised DP026:

• abn - what about sole traders?
• industryCode - needs to be optional as not all banks use ANZSIC 2006 (i.e. they simply cannot provide a valid value)
• agentRole - needs a more flexible model to allow for more than one role (e.g. CEO who is also Chairman)
• phoneNumbers - can we comply with E.164?

[NationalAustraliaBank]

NAB would like to stress the importance of taking a cautious risk-based approach to the development of the Open Banking/CDR data standards in Australia, especially with respect to the sharing of personally identifiable information (PII).

We believe we need to find the right balance between:

• Giving consumers the power of choice; which promotes the ability to drive more competition and innovation in the market; and

• Ensuring we do all we can, and all that we are obligated to do in order to protect consumers' critical personal information, which forms part of our duty of care.

We strongly believe that personally identifiable information that is currently used for the purposes of identity verification, password recovery or multi-factor authentication should not be shared with data recipients under any condition at this stage. It is worth noting that this point was highlighted in Farrell's 'Review into Open Banking' and supported by the ACCC's 'Rules Framework'; that any obligation to share customer data should not apply to information supporting an identity verification assessment and that data holders should only be obliged to share that information with the customer directly, and NOT with a data recipient.

Therefore, we believe that data such as Date of Birth (DOB) and mobile numbers are exceptional data fields that present a foreseeable risk to the consumer, especially in an unknown, unproven and untested data movement eco-system;

Additionally once shared the data will cease to have protection under the Australian Privacy Principles framework (as CDR data is being carved out of APP protection, and moved under the CDR safeguards). Once sufficient security protocols are in place and the accreditation process is proven, higher risk data (such as DOB and mobile numbers) can then be brought into consideration once again.

We would also like to highlight that our customers' DOB is not currently displayed to our customers in their existing channels and that their mobile numbers are masked when presented; Including these fields in the payloads also diverges from the principle covered in Decision Proposal 005 where:

"the APIs under the standard become another channel for a customer along side their existing channels with the same levels of access and servicing mechanisms"

From a consumer perspective the loss of this information has ramifications outside of the controls that are enforceable from any single data provider; ramifications that could impact customers in unexpected ways. For example, DOB and Mobile Numbers are currently used across many industries as a means of identity verification; if this information were to be compromised it could lead to a situation where identity theft could take place in other industries which are not yet directly quantifiable.

In addition to the security & privacy concerns expressed above, below are specific feedback comments on individual elements of the customer payloads.

In relation to the Person object:

Date of Birth (DOB)
Once again we would like to express our explicit aversion to the inclusion of this field within the standard in either of the payloads. We would like to point out that that DOB is NOT listed as a minimum data attribute required for inclusion within the ACCC's Rules Framework.
If a key aspect of the regime is to facilitate competition by helping customers to access other parties pricing, this does not (usually) require date of birth unless the product is only available to persons over a certain age. If the customer wishes to move their relationship to the third party, they can provide their DOB when giving consent to undertake Customer Identification Procedures (CIP) or KYC assessment (as noted above, Identity Verification / KYC assessment is specifically excluded from Open Banking at this time).

As a pragmatic compromise we would like to offer an alternative suggestion, i.e. to use flag(s) such as “isOver18” or “isUnder16” to enable the data holder to give a valid response to the data recipient if the customer is under the statutory age and the data holder is not required / permitted to disclose the information (depending on the rules regarding minors and consent of data sharing). This could also be used for other purposes such as age verification, which further increases the utility of the regime without creating unnecessary exposure for those early adopters of the scheme who we should in fact be looking to protect the most.

Mobile/Phone Numbers
We believe that if shared, they should be tokenised only just as they are currently presented within our channels today. In many situations customers have stipulated their preferences regarding when they can and should not be contacted, sharing this information without the appropriate preferences in place could lead to uncontrollable unsolicited communication.

Email Addresses
We believe that there is no need to share email addresses with third parties as they should be able to obtain this from their customers during their registration processes. From a security standpoint, email addresses are often used as part of the user credentials for authentication and also for multi-factor authentication, as such the aforementioned logic applies.

Gender
We question the use cases and purpose for including gender as a mandatory field or even at all as an optional field. We also note that gender is not listed as a minimum data attribute required for inclusion within the ACCC's Rules Framework.

Occupation Code
This information may not be readily accessible nor consistent for all data providers, we note it is an optional field but would prefer a situation where there is consistency across the implementations of the CDR from the onset.

In relation to the Organisation object:

General feedback around the processes surrounding Complex Authorisations
It is not clear how multi party authorisations will be managed within this standard. In the absence of this, can we assume that the single customer payload would capture the requester's party details only (noting this user, may in fact be an agent of the customer and not the customer themselves)? These concerns were also raised by speedyps and CBA. We also believe that further work on the complex consent and authorisation flows must be done before the customer payloads are finalised.

Registered address
What is the definition of the registered address type? Is this a residential address for individuals and the business address for businesses?

organisationType
We do not believe that there is adequate coverage for Not For Profit entity types (such as Associations, Co-operatives, Religious Bodies, etc). Also, how would we manage types that do not fit logically within the listed organisational types? Could we include "OTHER" as a fall back option?

ABN
If a person is a sole trader should they provide an ABN as well as personal name?

isPreferred
Why is the “isPreferred” flag mandatory?

isACNCRegistered
What is the purpose of capturing a flag “isACNCRegistered” within the payload?

establishmentDate
We believe this field name and description is arbitrary and will produce inconsistent data so it needs a description or a better name.

industryCode
We do not believe that industryCode should be a mandatory field.

Postal Addresses

Address validation is a complicated and arduous process; mandating that data providers present all of their customer's data which has been collected for many years into one simple structure will not be an easy task. We strongly believe we should be pragmatic on this decision, higher order standardisation is a legitimate function that third party data consumers could enrich upon in an open data eco-system in more efficient ways once the data is exposed.

That said we should aim to be consistent where it is simpler to do so e.g. a standard set of abbreviations for enumerations like street type or state etc. should be proposed in the standard.

Links
links is currently described as an Object whilst it should be a Array

General Comments:

What exactly does mandatory, optional & conditional mean? Is mandatory only mandatory if this is captured and held by the data holder? Is it possible to never provide optional fields even if they are held by the data holder?

[JamesMBligh]

I am leaving this proposal open until COB Monday at the request of a number of stakeholders

-JB-

[MacquarieBank]

Macquarie recommends the following modifications to the Customer payload:

The data model should allow for multiple organisations to be returned, rather than just one. A person can have roles in many organisations (these can be closely related organisations such as parent/subsidiary companies).
The data model should allow for multiple roles (agentRole) to be returned within the one organisation. A person can also have multiple roles within an organisation.

We believe this would result in a more flexible data model, with virtually no additional complexity.

[sakimura]

Since I have not fully grasped the use-case and request/response security characteristics yet, here is only a little bit of feedback. Once I get the details of use-case and request/response characteristics, I may provide more comments.

1. From the surface, and based on some of the comments, it seems it is trying to provide information about the person who authorized the specific action. I presume that this authorization is encapsulated in a token or similar format. Then, there have to be some ways of providing this token to this endpoint but it is not clear from the attached PDF how it is going to be done. Clarification would be appreciated.

2. If this is the use-case, then Userinfo endpoint of OIDC or token introspection endpoint of OAuth might be a candidate to achieve it. In the previous reply, it was stated that Userinfo endpoint was not used because it is expected that the payload will expand with time, but as the Userinfo endpoint is fully extensible, this does not sound like a good reason. Quite a bit of consideration went into specifying the Userinfo endpoint that covers some of the concerns raised in other comments, e.g., using E.164 as the phone number format, Addresses claim including "formatted" to accommodate the address format that cannot be captured in the usual street-locality-region-postal_code-country scheme.

3. One should be cautious in using the payload of such endpoint as a proxy to an authentication result. Many services including some of the leading social network were plagued by this misconception and causing data leakage/privilege escalation, etc. If it is to be used as something that identifies the authentication happened for the current session, then one should look at something like ID Token instead. Unlike access token whose ultimate audience is the resource, the audience of ID Token is the client. It has the issuer, issue date, expiration date, nonce, etc. that are required to make it safe for this kind of use. Also, it is worth noting that such data structure cannot be defined without getting into the detailed protocol flow.

[ellenbroad]

Adding some comments on the customer payload from discussions with a couple of consumer groups, and which have started to be raised internally at Data61 in the context of the user experience work stream. Posting here for the broader debate already underway.

There's some confusion about what the use cases would be for the inclusion of certain categories of information (e.g. gender, occupationCode) in the payload, that we need to be able to articulate clearly if they are in version 1. Including sensitive characteristics like gender as a mandatory field in v1 has been raised as a concern, as consumers may wish to pick and choose services they provide information about gender to. There's concerns occupationCode as provided at the time data was originally collected could be out of date when included in the payload for consumers sharing data under the CDR regime. It's important that we map our payloads back to use cases and test what is and isn't included with end consumers.

EB: this is what the user experience work stream is rapidly getting stuck into, with Meena Tharmarajah and Michael Palmyre joining Data61 to drive it forward. There's a UX mailing list through which workshops and outputs are being organised and shared. We're discussing how to use the GitHub repo for UX discussions, and what we need to be collating in a broader web presence (coming soon). You can sign up here for updates on UX here in the interim: http://eepurl.com/dCNaTf. The comments made about aligning payload proposals with use cases echo some of what needs to happen through that work stream.

[JamesMBligh]

Thanks for all the feedback. I’m closing feedback while a final recommendation is formulated.

-JB-

[JamesMBligh]

Having now had a chance to fully review the feedback here are comments indicating how the final decision will be posed. Note that this decision is for the draft version only. There will be additional time to provide feedback on the whole standard after the draft is released so nothing is set in concrete.

Address
There is conflicting feedback on the address structure alternating between using full G-NAF or PAF format and using a less structured format. This is hard to reconcile. As a result two options using and address$type will be included in the payload. This way a provider can choose to format the address according to the most specific data they have. Note that international addresses also need to be supported so G-NAF or PAF can not be used in all scenarios. This is why the state field was not prescriptive on format. An attempt will be made to address this in the final decision (pub intended).

Specific Customer Fields

• occupationCode - this will be left as optional
• DOB - the Farrell reports recommendation around excluding identity verification data referred to identity verification at time of onboarding (ie KYC) as opposed to phone based verification. This field will still be removed in the interim. It can be added back later as needed using end point versioning
• gender - this field will be removed based on feedback
• previous names - this will not be included. The intention is to provide the current accurate data for the customer

Specific Org Fields

• industryCode - it is understood that industryCode must be captured in ANZSIC format by Banks to support ATO reporting. Regardless, for the draft standard this will be made optional as this will also support multi-industry
• organisationType - the enum comes from the definition of organisation types recognised in Australian legislation. Based on feedback, GOVERNMENT_ENTITY and OTHER will be added
• ABN - I checked every major Bank's web site and they all indicate that an ABN is required in order to obtain a business account (even for Sole Traders). To support historic accounts, however, this field will be made optional.
• isACNCRegistered - this field indicates that the organisation is known to be a registered charity or not for profit
• establishmentDate - this refers to the date of establishment of organisation (equivalent to date of birth of the organisation). As this is not used for any form of authentication it will be left in the payload

Phone Numbers
The breakdown of numbers is to allow for a more specific structure and is useful in some situations. The fullNumber field allows a shortcut for data consumers that simply want to facilitate a phone call. This is equivalent to the Address granularity discussion. The fullNumber field will be marked up to support RFC3966 as recommended.
With regard to phone number purpose, international is a valid option, especially for sole traders running import/export businesses so it will remain. It does not have to be used, however, if this data is not captured by a specific provider

Email Purpose
The purpose field is not solely for timing of contact and is useful in manual contact scenarios.

Agents Of Organisation
It is valid feedback that individuals working for organisations may not want there details shown when sharing their organisation's information. The two structures will be collapsed so that only organisation or customer is provided. Within organisation only minimal information for the individual (such as name) will be included

Linking To Accounts
Linking account resource to authenticated user. Call the accounts payload. Authorisation is provided in the context of a specific user account

Definition Of Optional
The terms Mandatory, Conditional and Optional for fields indicate how the schema will be validated. It does not mean that optional fields need not be populated even if the data provider holds that information. In fact this would be a violation of the intent of the Consumer Data Right, which is to allow the customer control over their data. Optional therefore implies that there are expected circumstances where the data is not held. If the data is held it is expected to be returned.

-JB-

[JamesMBligh]

The finalised decision for this topic has been endorsed. Please refer to the attached document.
Decision 026 - Customer Payloads.pdf

-JB-