Decision Proposal 044 - Draft Standards Feedback Cycle 3

[JamesMBligh]

This issue has been opened to capture feedback on the standards as a whole. The standards site will be incrementally updated to accommodate this feedback. This is the third cycle of holistic feedback for the standards.

-JB-

[speedyps]

One more issue in the Swagger

/banking/payees

Type parameter has enum of DOMESTIC, INTERNATIONAL, BILLER, but default is ALL. Does this mean there should be an ALL type, or should the default be something else.

[JamesMBligh]

Thanks @speedyps. This was an oversight. FIxed now.

-JB-

[speedyps]

Question on GET /banking/accounts/transactions and POST /banking/accounts/transactions

I don't think the proposed response object can handle multiple accounts.

The response object looks like it will only process for a single account. I'm very happy to be wrong.

I think the expected response either has to look like:

{
    "data": [
        {
            "accountId": "1000000001",
            "displayName": "Online Current Account",
            "nickname": "Business A Current Account",
            "transactions": [
                {
                    "transactionId": "d36924c2-3d1a-4a54-b7fe-7f3bccc350ec",
                    "isDetailAvailable": false,
                    "status": "POSTED",
                    "description": "ATM DEPOSIT - QVB SYDNEY NSW",
                    "postDateTime": "2018-10-05T00:00:00Z",
                    "executionDateTime": "2018-10-05T00:00:00Z",
                    "amount": 300.56,
                    "currency": "AUD",
                    "reference": ""
                }
            ]
        },
        {
            "accountId": "1000000002",
            "displayName": "Rapid Save Account",
            "nickname": "Business A Tax Account",
            "transactions": [
                {
                    "transactionId": "d36924c2-3d1a-4a54-b7fe-7f3bccc350ec",
                    "isDetailAvailable": false,
                    "status": "POSTED",
                    "description": "PAYMENT FROM BOB SMITH, INV #291978",
                    "postDateTime": "2018-10-05T00:00:00Z",
                    "executionDateTime": "2018-10-05T00:00:00Z",
                    "amount": 262.21,
                    "currency": "AUD",
                    "reference": "INV #291978"
                }
            ]
        }
    ],
    "links": {
        "self": "http://example.com/cdr-au/v1/banking/accounts/transactions?page=1&page-size=25"
    },
    "meta": {
        "totalRecords": 2,
        "totalPages": 1
    }
}

or

{
    "data": {
        "accounts": [
            {
                "accountId": "1000000001",
                "displayName": "Online Current Account",
                "nickname": "Business A Current Account",
                "transactions": [
                    {
                        "transactionId": "d36924c2-3d1a-4a54-b7fe-7f3bccc350ec",
                        "isDetailAvailable": false,
                        "status": "POSTED",
                        "description": "ATM DEPOSIT - QVB SYDNEY NSW",
                        "postDateTime": "2018-10-05T00:00:00Z",
                        "executionDateTime": "2018-10-05T00:00:00Z",
                        "amount": 300.56,
                        "currency": "AUD",
                        "reference": ""
                    }
                ]
            },
            {
                "accountId": "1000000002",
                "displayName": "Rapid Save Account",
                "nickname": "Business A Tax Account",
                "transactions": [
                    {
                        "transactionId": "d36924c2-3d1a-4a54-b7fe-7f3bccc350ec",
                        "isDetailAvailable": false,
                        "status": "POSTED",
                        "description": "PAYMENT FROM BOB SMITH, INV #291978",
                        "postDateTime": "2018-10-05T00:00:00Z",
                        "executionDateTime": "2018-10-05T00:00:00Z",
                        "amount": 262.21,
                        "currency": "AUD",
                        "reference": "INV #291978"
                    }
                ]
            }
        ]
    },
    "links": {
        "self": "http://example.com/cdr-au/v1/banking/accounts/transactions?page=1&page-size=25"
    },
    "meta": {
        "totalRecords": 2,
        "totalPages": 1
    }
}

Cheers

Peter Speden

[speedyps]

Alternatively, I would suggest not having the displayName and nickName and then just embedding the accountId in the transactions section.

I personally think the responses should be more atomic - ie only have transaction information in the transaction responses.

[speedyps]

I would also request that there be some clarification on how the paging and record numbers work in this case.

I am guessing the aim is to return the number of transactions, which is fine.

In the case we have above, we could split the transactions for an account across pages. Does this mean that the Account header gets repeated when we ask for the following page?

I was involved in a project using DDA where the bank tied themselves in knots over how the paging and number of records worked, because it was not clarified and open for interpretation.

Cheers

Peter Speden.

[JamesMBligh]

Thanks @speedyps - what you have suggested was the actual intent (based on the feedback from cycle 2 and the agreed response). If the nickname, etc is still there then it is likely a mistake in the translation of the intent. I will review and fix if that is the case.

As clarification, the intent is that the record and page counts represent the totals for the full domain of transactions available under the filter and that the order is by date/time without account aggregation.

-JB-

[JamesMBligh]

I think transaction schemas and samples should now aligned to the decisions from cycle 2. Please let me know if I have missed anything.

-JB-

[anzbankau]

Person Detail.phoneNumbers: Mandatory, At least one record is required
Could you please explain the rationale for making a customer phone number mandatory. While it may be necessary for establishing a service (e.g. to permit two-factor authentication), thereafter a customer is entitled to ask for their phone number(s) to be removed from their customer profile. While customer service staff can advise the customer of any consequences of not having a phone number, the customer may still proceed. This obviously has consequences for existing consents (i.e. we couldn't share data if phone number is mandatory) and for new consents (i.e. potentially preventing a new consent).

[anzbankau]

Balance.DepositBalance & LendingBalance Types
The DepositBalance & LendingBalance types seem to have lost their Descriptions in version 0.2.0.

[deboraelkin2]

Get Bulk Balances (GET /banking/accounts/balances) and Get Balances For Specific Accounts (POST /banking/accounts/balances) share the same response data type, ResponseBankingAccountsBalances, which caters for pagination.
Get Bulk Balances accepts pagination request parameters, whereas Get Balances for Specific Accounts doesn't
My thinking is that it should, since the accounts list could potentially include all accounts belonging to a customer, making it equivalent to a Get Bulk Balances request

[deboraelkin2]

The Get Transactions APIs accept start-time and end-time as optional query parameters, and their default values are defined as:

• start-time: If absent defaults to current time.
• end-time: If absent defaults to start-time plus 100 days.

If these parameters are not specified, then the transaction search would return no results (it'd search for transactions in the next 100 days)

I believe their default values should be:

• end-time: If absent defaults to current time.
• start-time: If absent defaults to end-time minus 100 days

[sachi-d]

Hi all,

Please find the following feedback from Financial Solutions team at WSO2.

1. HTTP Headers

x-Correlation-Id is not documented in the HTTP Headers section. On the same topic, what is the use of having two headers (x-Correlation-Id & x-fapi-interaction-id) as correlation IDs?

2. Versioning

Endpoint versioning seems to have been introduced in order to release minor changes to the end points. Then what do we get as updates in standard version(eg: If the standard version is 1.0 can't there be a 1.1 version release? If there is, what kind of changes can we expect?)

3. Security

3.1. Authorization scopes

Can multiple authorization scopes be used in a single request?

3.2. Client-ID

In Information Security Profile, Section 5.1,

• the JWT claim “iss” and “sub” are defined as the client-ID of the bearer
• the “client_id” of the request parameters is defined as the ID of the calling Client

Are these two equal? The concern was raised due to different values present in the sample.

4. Banking APIs

4.1. Error Flows

In data retrieval calls for specific accounts:

• POST /banking/accounts/balances
• POST /banking/accounts/transactions
• POST /banking/accounts/direct-debits

In the request body, a list of account IDs is to be specified. In case of one or more account IDs are found to be invalid, should the response be an error response, or should the response be a data response with the specific array element containing an error message? Adding examples for error flows like this would make the standard more effective.

4.2. The difference between “Get Transactions for Account” and “Get Transactions for Specific Accounts”

The Get Transactions for Account call, is presumably used to retrieve transactions of a single account

• GET /banking/accounts/{accountId}/transactions

The Get Transactions for Specific Accounts, is to retrieve transactions of multiple accounts, when the accounts are defined using an array in the request body.

• POST /banking/accounts/transactions

Is there a specific need for the first API, when the same can be retrieved using the second API? The same concern applies for direct-debits.

4.3. Need of accountId with the unique transactionId

In transaction detail retrieval:

• GET /banking/accounts/{accountId}/transactions/{transactionId}

If transactions ids are unique do we need to pass an account ID?

Cheers,
Sachithra Dangalla,
WSO2 Financial Solutions Team

[WestpacOpenBanking]

Scheduled Payments

As the 21st of December ACCC CDR rules outline mentions the need for scheduled payments (4.17 c. iii.) Most likely a new decision proposal will be needed to accommodate this.

Direct Debits

The rules outline makes reference to direct debit deductions (4.17 c. i.) rather than direct debit authorisations. The direct debits endpoint part of the standard will need to be discussed and adjusted accordingly.

Requests for clarification

• We are currently not sure how to interpret productName, nickname and displayName in the Account object (and have noticed the note in response to the draft standard feedback). Updating the example to use something other than “string” would help us here.
• x-fapi-customer-ip-address ‘indicates that a customer is present’ is this the ‘device header’ which the NFR proposal refers to?

Minor things to fix

In addition to some of the known issues with the standard, like the missing indications of conditionality in the HTML documentation, we’ve noticed the following minor errors, omissions, inconsistencies, etc in recent standard updates:

• The description of displayName in the Account object appears to be from the original decision proposal for basic account details, rather than the updated description from the decision (where nickname was added as an additional field). Currently both fields might be a nickname if one exists and we don’t know if this was intended.
• The 504 Gateway Timeout code description has a missing “e” in “us 500 instead”
• The Sample union object structure json has “shapeType” where “shapeUType” was probably expected.
• Descriptions (and conditionality as noted in the known issues section) are missing from many fields and needed in some cases. This includes:
  • The balance, lending (as identified by @anzbankau) and purses fields in Balance
  • The person and organisation objects lack their descriptions (and hence conditions of inclusion) in both ResponseCommonCustomer and ResponseCommonCustomerDetailed
  • Notwithstanding our other feedback on direct debits, the authorisedEntity property of DirectDebits
  • Enum lists don’t have a description field. Examples:
    * The product-category enumated values all have no description.
    * Product feature enumerated values like feeType or discountType are missing both a description and the usage of the additionalValue field.

[AmexAUopenbanking]

Decision Proposal 044 - Draft Standards Feedback Cycle 3

• Date of Birth : This field has since been excluded from the data standard. The CDR data standards and security profile should be built to be robust/secure enough for such sensitive data. Date of birth field could potentially be useful for fraud prevention, credit bureau matching, and personalisation use cases. The Open Banking review recommended that a data holder should be obliged, at a customer’s direction, to share all information that has been provided to them by the customer. Although in the ACCC draft CDR rules framework DOB was not included in the proposed minimum customer data set, we note this was not a definitive list of all customer data elements. As an alternative could DOB be included in a different data payload with a more complex data set or if this is not possible could a DOB ‘year range’ be included?

• ABN Fields – This field is listed as Required - False. The intention of the data standards should be made clear that if the ABN field is available with the data holder it must be populated. i.e. it is specified as a non-mandatory field only as not all accounts may have an ABN accessible.

• Simple / PAF address - Both simple and PAF address are listed as Required - FALSE. We understand the intention to be that a customer’s address must be provided if stored by the data holder, however; data holders may provide either simple or PAF address as appropriate. Clarity should be given of the intention behind ‘Required’ definitions.

[sandstoneau]

Phone Number Purpose
After carefully reading through Decision Proposal 026 and associated discussions, we found that the question/feedback we wanted to mention was already raised by da-banking here:

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.

The response to this suggests there is a valid use case for it

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

We wanted to note that the suggested use case (even as described) is not fully clear and we expect other consumers of the API specification may also not be aware of this and may instead misconstrue the purpose of the field more in line with da-banking and our own initial reading. We are guessing it may be related to https://www.itu.int/en/ITU-T/inr/unum/Pages/uifn.aspx ? Having some better exposition of the use case in the field definition might quickly help implementers determine they can ignore the field. One example misinterpretation would be for an implementer to set a WORK or MOBILE purpose phone to INTERNATIONAL just because the country code is not +61. Consumers of the API may have similar confusion.

[anzbankau]

Hi James,

With regards to the transaction API - in the scenario where a point in time response was available due to an error state e.g. when there is an issue with providing intraday transaction data and only prior day is available – What is the expected behavior? Would a data holder respond with available information, reject the request or provide a response containing a warning code?

[commbankoss]

1. General Response to the Standards version 0.2

1.1 Versioning

Commonwealth Bank would like to advocate that upon recognition and amendment of version 1.0 standards based on this round of public feedback, that any additional changes to the API's move to a future version (1.1 or 2.0 based on the significance of the change). Amendments introduced throughout the drafting process of the initial standards version has seen considerable effort to allow for the analysis and development of additional fields into the APIs.

As we are now close to the regime supporting versioned API endpoints, Commonwealth Bank would like to seek clarity in regard to the expectations of the data provider supporting changes introduced through minor API specification revisions. Commonwealth Bank would also seek a proposal from Data61 as to how impact assessments will be conducted deeming whether a proposed change should be introduced through a minor or major revision.

1.2 HTTP Headers

Commonwealth bank seeks clarification about the introduced x-fapi-interaction-id header field and if it is intended for the purpose of being a correlation id that can be used to track any given transaction between consumer and data holder. If so, we would seek that the x-fapi-interaction-id be represented in both request and response headers as mandatory. If the x-fapi-interaction-id is not for used for this purpose, we would seek the x-Correlation-id header field to be included as both a request header and a response header with both as mandatory.

Commonwealth bank also recommends the requests headers include a mandatory specification for the header fields.

1.3 Payload Conventions

Commonwealth Bank would encourage Data61 to elaborate on an industry definition of optional and mandatory. We consider an appropriate approach is to define 'mandatory' fields as referring to the core data fields required in a response. Where a data holder does not hold data for a mandatory field, an empty string could be returned but a data holder must return a response. 'Optional' fields should refer to non-core data fields that a data holder may provide at their discretion. The latter category could extend in future versions to potentially chargeable data fields that may not be held by all data holders or standardised across the industry.

Commonwealth bank seeks clarification on the response from Data61 specifying "All fields are mandatory if data exists". Commonwealth Bank understands that data to be made available under the CDR refers to those sets available to consumers via digital channels, and further that Data Holders will not be required to create data sets or convert data not held in an appropriate format in order to make that data available under the CDR.

1.4 Pagination

Commonwealth Bank does not support the recommended approach by Data61 for standard pagination. The design proposed could be seen as a direct anti-pattern to what leading technology companies do today. These companies are renowned for handling large data sets and leading innovation. This is particularly important when institutional customers become in scope it is imperative that the Open Banking eco-system can support these data intensive institutions. A standard pagination solution assumes data is static and not dynamic. It also considers only record count instead of each individual record. When complex problems like reversals are applied on transactions, they can not be solved simply by the proposed Data61 solution.

Commonwealth Bank are in favour of the industry suggested approach of 'cursor based pagination' using continuation tokens. Leading technology companies leverage the concept of continuation tokens enabling real-time data availability. We support Westpac's recommendation to implement cursor based pagination through first/next/prev/last links. However, Commonwealth Bank would also say that the last link is not necessary in true cursor based pagination.

We also agree with Westpac regarding how the performance benefits of the cursor based approach will not be fully realised if page , totalRecords and totalPages are required in each query. Using these elements will not allow us to align our cursor based pagination with industry-led designs. Therefore, Commonwealth Bank supports the recommendation to exclude page , totalRecords and totalPages from the response.

2. Security

2.2 Authentication Flows

Commonwealth Bank maintains its position that a decoupled authentication flow is the most secure option for consumers and is, therefore, our preferred authentication flow option. In a decoupled flow consumers provide authentication and a scope of the data sharing request directly to their bank. However, the Standards continue to mandate the use of an Open ID Connect Hybrid (OIDC Hybrid) approach. The OIDC Hybrid approach, which features redirection from the data recipient's website or application to the Data Holder, which create unacceptable phishing risk to consumers in the following ways:

• An attacker could gain access to a data recipient's application and change the redirect URL to a malicious website;

• An attacker could create a fake website posing as the Data Holder where they harvest bank credentials; and/or

• It may encourage consumers to adopt insecure behaviour and trust redirect links purporting to be authentic URLs, to the point where they enter banking credentials.

Section 17.2 of the Standards states that as part of the OIDC Hybrid approach, "it is important from a usability perspective that the Data Holder authentication choices presented to the end-user are consistent with those currently utilised by the end-user when accessing their existing Data Holder online accounts". Commonwealth Bank is concerned that this will encourage consumers to adopt insecure behaviour. We are not supportive of consumers using any of their existing banking credentials with third party applications.

The Standards allow, but do not mandate, the use of a decoupled variant known as Client Initiated Back Channel Authentication (CIBA). Though not as secure as a truly decoupled approach, which would be our preference, CIBA represents a more secure approach than the OIDC hybrid approach and of the two is our preferred alternative.

However, we would like the Standards to provide further detail on the implementation of CIBA, including greater clarity regarding the unique customer identifiers that consumers will be required to provide to data recipients. It is still not apparent what data can be used as a unique customer identifier and how the unique customer identifier is confirmed by the data holder. We are extremely concerned that sensitive information (such as mobile or banking credentials) may be used for this purpose, exposing consumers to unnecessary risk and making them more attractive and lucrative targets to cyber criminals. Commonwealth Bank would recommend that a unique token be generated in the flow and used as unique customer credential identifier.

2.3 API Endpoint

Commonwealth Bank would like further clarification in Section 11.3 regarding calls to API endpoints made by data recipients to data holders. We note that API calls requesting access to protected resources, such as consumer data, will require mTLS (as clarified in the revised Section 5) for channel encryption. However, we recommend the Standards also explicitly require the use of certificate bound access tokens to be presented across that channel as part of the same API call. This requirement, will ensure that a token is more difficult to misuse or re-use, even if it has been compromised. Though this requirement is aligned with the Internet Engineering Task Force guidelines, it is not explicit in the current draft.

2.4 Directory and Certificate Revocation

Further details regarding the Directory and Certificate Authority are still required. There are limited details regarding the scope of the services and expectations of the Certificate Authority (CA) or the Directory.

The Directory underpins the functioning of the Open Banking Regime since, if functioning properly, it will provide a source of truth for identifying legitimate participants in the Open Banking regime. The Certificate Authority (CA) manages and issues the security certificates and public keys used for secure communications between Data Holders and Receivers. Accordingly, the CA is central to establishing trust between the participants and therefore crucial to Open Banking. Our concerns are detailed in our review of the previous draft of the Standards.

2.5 JWKS Endpoint

Commonwealth Bank would like further clarification in Section 13.6 of the Standards on whether the JWKS Endpoint should be used by a data holder to obtain the public key used for encrypting ID Tokens.

3. Banking APIs

3.1 Bulk Mandatory

Commonwealth Bank recommends changing bulk APIs to an optional requirement, aligning with the specifications within the UK Open Banking regime. Supporting bulk endpoints for both data holders and data recipients would require significant engineering effort. Additionally, we do not make bulk transaction data available today, and requiring the creation of new datasets is not in line with the principles of the regime.

In addition, Commonwealth Bank recommends not including mandatory bulk endpoints until issues surrounding pagination have been solved. Whilst Data61 has determined the concerns from the industry around implementation of bulk endpoints will be resolved through non-functional requirements, the main issues arise from the pagination approach. The pagination rules will not be able to support bulk end points and could increase performance constraints on the eco-system unless continuation tokens are used.

3.2 Account Payload

3.2.1 Closed Accounts

Commonwealth Bank would like to acknowledge the other data holders concerns for the implementation of closed account information by the required July time frame. There is considerable effort involved in transforming stored data from previously closed accounts. Due to the change in the required scope of closed account information, we request a change in the deliverable timeframe to February 2020.

3.2.2 Balances

Commonwealth Bank is concerned around the mandatory inclusion of a balance payload for every request of an account (basic or detailed). Commonwealth Bank acknowledges that the balance information has been moved to the detailed account endpoint. However, we would recommend complete separation from the account endpoint to a new endpoint with separate authorisation scope and URI.

The traffic usage of the account detailed endpoint will increase due to the inclusion of balance information. Balance and account specific pricing, features etc. are derived from different source systems. By increasing the traffic to this endpoint there will be unnecessary risk exposure to infrastructure. The separation of these endpoints is the optimal solution, as it would provide security to core banking systems and sensitive customer information. This would help prevent unnecessary data leakage in scenarios where account features are needed but balance is not required (such as product comparison). Lastly Commonwealth Bank would recommend further testing in the CX stream to see if this is a concern with vulnerable consumers.

3.2.3 Account Query Parameters

3.2.3.1 is-owned

Commonwealth Bank recommend that 'is-owned' query parameter be removed. Only accounts owned by a consumer will be shared by the consumer therefore making this redundant. Commonwealth Bank are unsure about the relevant use case for this query parameter and field type.

3.2.4 Account Fields

Commonwealth Bank is partially supportive of the proposed account payload but has concerns regarding the requirements for detailed personalised account parameters. Implementing individualised features, fees/discounts, depositRates and lendingRates on an account is challenging to deliver, specifically:

• Account level parameters is a calculation derived from multiple discrete components.

• A calculation must be performed at time of enquiry to produce accurate pricing and as a result a stored (cached) price would be inaccurate.

• The amount of workload this introduces creates risk of overloading core banking systems, putting the overall data ecosystem at risk

We would recommend that Data61 defers the mandatory detailed account endpoint to a laterVersion of the Standards to ensure adequate time for data holders to enable this capability.

3.3 Payee Payload

Commonwealth Bank would like to re-iterates our concerns raised in our previous submission concerning the Payee payload. We recommend further review by the information security working group regarding the potential of personal information leakage. In addition, there has been an inclusion of further requirements to the payee payload which will impact our ability to comply with phase one. These new requirements are expecting us to create data that does not exist today in our core banking systems, therefore we expect that such data will only be required where already held and made available by a data holder.

3.4 Transaction Payload

3.4.1 Transaction Query Parameters

3.4.1.1 Transaction Status

Commonwealth Bank acknowledges Data61's position on the inclusion of pending transactions as a valuable subset of data. However, we would encourage reviewing the value of this data from a data ingestion perspective.

The pending transaction data will require internal manipulation and each data holder may calculate the data differently. This will give the consumer different experiences to what they might receive in their current digital channels. The inclusion of pending transactions may also create complexity and data quality concerns around the treatment of expired pending transactions. Commonwealth Bank would recommend validating the benefits of the pending transaction data during the revised piloting stage before releasing for accredited data recipients.

Commonwealth Bank recommends that only reconciled transactions be included in the regime to ensure data quality.

3.4.1.2 text - search

Commonwealth Bank does not support the inclusion of search-based functionality (text, min-amount, and max-amount) as a method of filtering the transactions payload. This is a feature that should be constructed by the data recipient, to enable a consistent user experience across institutions.

In the response from Data61 Feedback Cycle 1 – "It is also understood that there are a number of implementation options to reduce to the performance impact of a multi-field text search." Commonwealth agrees with Data61 about optionality to reduce performance impacts and recommends that text search querying should be limited to a specific indicated field with a specific value. While this implementation would reduce performance impacts, under the CDR data holders are not required to enrich data in order to make that data available. This query is a computationally expensive aggregation and would not support the implementation as we do not currently provide this information in our digital assests.

3.4.1.3 date filter parameter

Commonwealth bank supports date-filter parameters and would recommend the following default values to have a logical basis e.g. 8 weeks or 3 months. We recommend that when the parameters are left absent the following format should be used; start-time: current time and end-time: start-time minus 90 days.

3.4.2 Transaction Fields

Commonwealth Bank again would like to highlight the new field requirements which have emerged in the updated Standards (1.1 Versioning). Continuing to increase the scope which will create greater constraints on our ability to deliver a desired minimum viable product for compliance.

3.4.2.1 Transaction Type

Commonwealth Bank acknowledges the value a transactionType field would provide to data recipients. Commonwealth Bank would like to express that transaction type is a field type that we do not currently provide in our digital channels. The solution recommended by Data61 will require the data holders to conduct considerable mapping to transform raw data. In addition, if not clearly defined, each bank could use different codes to identify the transaction types indicated by Data61. Depending on how each data holder defines these codes, the resulting transactions types may not be aligned between data holders and will create confusion for data recipients.

Commonwealth Bank would recommend that if this field is required by data recipients, the data holders provide the raw transaction type data in a string form, therefore removing complex mapping activities that could possibly derive limited value for the consumer.

3.4 Product Payload

Commonwealth Bank does not support the current data model for version 0.2.0 of the Consumer Data Standards (1.1 Versioning). Commonwealth Bank is supportive of a revised version of the product API to reflect the proposal from the Australian Banking Association.

3.4.2 Product Fields

Commonwealth Bank again would like to highlight the new field requirements which have emerged in the updated Standards. Continuing to increase the scope will intern greater constraints on our ability to deliver. We recommend focusing on key attributes for phase and iterate in future versions of the Standards.

3.4.2.1 Loyalty Points

Commonwealth Bank is supportive of the inclusion of Loyalty points name in a later version of the Standards, the recent addition of this information is expanded scope at a late stage which will be difficult to deliver by 1 July 2019.

3.4.2.2 Bundles

Commonwealth Bank is not supportive of the recent inclusion of an array for productID in the bundles of a product.

The current proposal is impractical and unnecessarily complex- it is not feasible to include every permutation of a bundle to productID association. In the proposal from the ABA, industry did not support the structural design of this proposal and instead recommended a solution which derives access from the Bundle rather than the Product. This is a complex problem space which requires an additional dedicated endpoint and should be a concept introduced in a later version of Open Banking interfaces.

4. Common APIs

4.1 Customer Payload

Commonwealth Bank is not supportive of the inclusion of a 'customer' API and have ongoing concerns about the structural design of the payload. Data61 has stated that financial institutions have designed their capabilities differently and the structural issues should be handled internally. Commonwealth Bank believes that we can create a solution that is consistent across industries and not subjective for data holders to create bespoke experiences which would introduce customer friction. Commonwealth Bank has opened a separate issue on GitHub to discuss scenarios where the Data61 'customer' payload are not able to support complex entity structures.

4.1.1 Customer Fields

4.1.1.1 phoneNumbers

Commonwealth Bank questions the appropriateness of making a phone number mandatory for each customer. Phone numbers are not unique to single customers and can be duplicated across multiple customers. This is also highly sensitive information that is used for verification and not required for data recipients in relation to customer propositions.

4.1.1.2 PhysicalAddressWithPurpose

Commonwealth Bank would seek to exclude this field from the Standards. This is not information that is currently captured through a standard on-boarding process and would require changes across multiple channels not limited to digital. By defaulting this field to REGISTERED incorrect information may be sent to an incorrect address, exposing the consumer to potential fraudsters.

4.1.1.3 PAFAddress

Commonwealth Bank would seek to exclude this version of standardising address information. There will be considerable engineering effort required to uplift current systems to comply with this Standard.

4.1.1.4 legalName

Commonwealth Bank recommends that the legalName field is made mandatory, Commonwealth Bank is required to obtain this information through a standard on-boarding process.

4.1.1.5 businessName

Commonwealth Bank recommends that this field is made optional. Every organisation has a legal name but only some will have a business name. A customer can trade under multiple business names so we would recommend making this an array.

4.1.1.6 agentRole

Commonwealth Bank does not have this data available today via digital channels and would seek for it to be excluded from the Standards. As stated previously, requiring the creation of new datasets is not in line with the principles of the regime.

4.1.1.7 Sensitive Data

Commonwealth Bank would recommend excluding the below information from the customer payload as it is considered sensitive consumer information used for verification purposes and the inclusion could lead to considerable data leakage and potential fraudulent activities.

• occupationCode
• phoneNumbers
• emailAddresses
• physicalAddresses

5. Other

5.1 Non-Functional Requirements (NFRs)

Commonwealth Bank is broadly supportive of the non-functional requirements proposed by Data61 but would seek clarification that:

• 'Sessions' refers to the number of times an access token is granted in a period of time.

• 'API Calls' refers to the number of calls to an Open Banking API (excluding FAPI calls) in a period of time.

• 'Transactions' is analogous to API calls.

• 'TPS' refers to the number of API calls (Transactions) in a second.

Commonwealth Bank believe that in principle there should be limitations on threshold amounts to enable better success and stability of the Open Banking eco-system. We hold the view that the following thresholds should be sufficient for the expected traffic across data holders.

• 300TPS total across all consumers

• 50TPS per consumer

Commonwealth Bank recommend that the above thresholds be the minimum requirement and that data holders may internally choose the maximum limit, with the caveat to not adversely affect other participants. There is currently no indication of minimum requirements in the NFRs decision proposal.

Based on the assumption that the session is associated to the access token Commonwealth Bank would recommend limiting the time allocated per a session to be 60 seconds. Limiting a session to 60 seconds will ensure security during a customer not-present session.

Commonwealth Bank does not support the concept of 'as in digital channel' in the data latency section of the NFRs. There are considerable differences between industry participants in the currency of their data, this is a point of competitive difference. A rule of channel parity disincentives investment in this capability and unreasonably burdens innovative participants. The standard should be set so that all data holders can comply with the same requirement.

Commonwealth Bank would like to support that Get Bulk Balances should be categorised within the Bulk performance tier and public APIs should also have thresholds.

Lastly Data61 have acknowledged that the Information Security NFRs have not been included in the initial decision proposal. Commonwealth Bank would recommend including them in the revised NFRs decision proposal. Data holders need clarification of NFR's in the revised proposal to incorporate this scope for phase one as they will have significant delivery impacts.

5.1.1 Reporting

Commonwealth Bank would like clarification on how Data61 would define current-time. There will be implications to the delivery timeframes based on this definition. Commonwealth Bank would recommend that the current day is defined end of yesterday for phase one of the version. As real-time capability is achievable across data holders Data61 can amend the current time definition.

5.2 Dashboard Requirements

Commonwealth Bank has been working through requirements for both data recipient and data holder dashboards. To create a consistent customer experience across dashboards the data holder should be notified about the use case of the data.

In order for customers to have full transparency and ease of managing their data sharing from the data sharing 'dashboard', they need to be able to differentiate between multiple data shares set up with one data recipient. For example, data recipient A has two uses for CDR data; a budgeting application and as part of a credit card application. A consumer may decide that they no longer want their data shared for the purpose of the budgeting application but wish to continue sharing data for their credit card application. Currently there would be no way for the consumer to easily differentiate between shares outlined on the dashboard. Both data arrangements would both appear as 'data recipient A'. A better experience would be to include the use case, ie "Third Party A – Budgeting App" to help them make more informed decisions when managing their data sharing.

For example, data recipient A has two apps "Budgeting app" and "Credit card application". A consumer may decide that they no longer want their data shared for the purpose of 'Budgeting app', but currently there would be no way for them to easily differentiate between applications of sharing outlined on the dashboard. They would both appear as 'data recipient A'. Ideally we'd be able to include the use case, ie "Third Party A – Budgeting App" to help them make more informed decisions when managing their data sharing.

[JamesMBligh]

Happy New Year everyone. Thanks for the feedback to date. I intend to respond substantively in the next 24 hours. This feedback thread will be extended by a week until this Friday at the request of some participants.

-JB-

[JamesMBligh]

The following submission was received via email from FinTech Australia. It is provided here for transparency.
AUMatters - Fintech Australia Open Data - Consumer Data Standards Submission.pdf

-JB-

[JamesMBligh]

The following submission was received via email from FinTech Australia. It is provided here for transparency.
AGL submission - Data61 Technical standard - 18 January 2019.pdf

-JB-

[NationalAustraliaBank]

Summary

• NAB would like to thank Data 61 for the detailed response to feedback provided on the 2 November 2018 Working Draft of the CDR/Open Banking Standards.

• NAB is supportive of the recommended changes detailed by the ABA paper on Product Reference Data.

• We would also like to reiterate some feedback that has not been responded to.

• We will continue to provide incremental feedback as new information comes to light during our implementation; especially with respect to the evolution of the security profile and its impact on the data standards.

Feedback to DP039 not responded to

Product Eligibility Types

In our previous feedback we recommend the inclusion of an additional enumeration value to represent whether a product is available to a person (as opposed to organisations) suggesting a value of either INDIVIDUAL or NATURAL PERSON and ORGANISATION.

lastUpdateTime

We raised concerns about the intent & availability of the lastUpdateTime field for Person and Organisation APIs.

The exact intent of this field is not clear. For instance, it may refer to either the last time that the complete set of customer data has been reviewed and updated; or any individual data field has been updated. Depending on the intent, NAB may or may not hold this data or may be confusing. Given the uncertainty regarding the intent and accuracy of the field, we recommend the field to be removed or be made optional.

balance$type and associated structures

We note that several feedback items were responded to regarding balances, however our proposal to simplify this section has not been responded to. Out initial feedback is repeated below. An additional piece of information is that there are some business finance products that have a limit but do not actually hold a balance (Bank Guarantees & Letters of Credit).

We believe the way Balance and Limit are represented are overly complex and suggest this should be simplified.

A simpler representation is possible with only one "balances" object (allowing multiple balances and currencies) and a separate limit object. Our recommendation is summarised below:

• Create a new balances object as an array containing only the balances (see below)
• Create a new limits object and move limit details out of the LendingBalanceType into this object (see below)
• Remove the following objects - balance$type; PursesBalanceType; LendingBalanceType; DepositBalanceType

This allows any account to have one or many balances in one or multiple currencies.

This simpler representation delivers on the intent and is simpler to understand, interrogate and implement and is the most accurate representation of the data. An example of how this might be represented is below:

Balances

Name                 Type               Required    Restrictions      Description
» balances           [AccountBalance]   true        none              Array of balances on the account

AccountBalance Properties

Name                 Type               Required    Restrictions      Description
» accountId              string     true       none              The account ID
» currentBalance     CurrencyAmount     true        none              The current balance of the account at this time. Should align to the current balance available via other channels such as ATM balance enquiry or Internet Banking.
» availableBalance   CurrencyAmount     true        none              The available funds in an account. Assumed to be positive or zero.
» limits              [AccountLimit]     false       none              The credit limit details for the account

AccountLimit Properties

Name                 Type               Required    Restrictions      Description
» creditLimit        CurrencyAmount     true        none              The maximum amount of credit that is available for this account. Assumed to be positive or zero.
» amortisedLimit     CurrencyAmount     false       none              The available limit amortised according to payment schedule.
 

Fully elaborated example

{
	"data": {
		"balances": [{
			"accountId": "2345678AAA",
			"currentBalance": {
				"amount": "$300.32",
				"currency": "AUD"
			},
			"availabeBalance": {
				"amount": "$200.32",
				"currency": "AUD"
			},
			"limits": {
				"creditLimit": {
					"amount": "$5000.00",
					"currency": "AUD"
				},
				"amortisedLimit": {
					"amount": "$4523.00",
					"currency": "AUD"
				}
			}
		}]
	},
	"links": {
		"First": "...",
		"Self": "...",
		"Next": "...",
		"Prev": "....",
		"Last": "..."
	},
	"meta": {
		"totalPages": "3",
		"totalRecords": "12"
	}

}

Seek further clarity on feedback received

CreditCardAccountType

Thanks for clarifying the difference between minPaymentAmount and paymentDueAmount. Given your explanation that the two fields are required “to accommodate the scenario where a payment plan is in place where the payment amount is higher than the minimum payment technically required”, this scenario is not applicable to all credit cards so please change the paymentDueAmount to Optional (Required=false)

[anzbankau]

Clarification

1. We are seeking some clarification with regards to credit cards accounts our expectation the data is retrieve based on the account and not the card. An example is the direct debit endpoint when servicing a card account we should respond with all direct debits for all cards associated to the account. Can you please confirm?

Feedback
GET /common/customer

1. Naming consistency – Person.lastUpdateTime and Organisation.lastUpdateTime should be ‘lastUpdated’ to be consistent with Product.lastUpdated.
2. Person.lastUpdateTime & Organisation.lastUpdateTime – Note that Data Providers will source this last-updated ‘date-time stamp’ from source systems with a different data scope to that of Open Banking – encompassing other properties. As a result, it may differ from the date-time from a previous request even though the Open Banking person/organisation object itself has not changed. A Data Recipient using this to refresh their copy of the data could (if required) avoid an update by checking whether any property has actually changed. For example if address was not considered part of the primary customer object, the date would not change on the record even though the address had been updated. We suggest either removing the field or making this optional and put the onus on the consumer to compare or overwrite as required.

[JamesMBligh]

With regard to the feedback on phone number being mandatory. Phone numbers will be made optionally an empty array, although if phone number data is held it is still assumed that it will be mandatory to transfer the data.

[JamesMBligh]

The descriptions for Balance.DepositBalance & LendingBalance Types will be restored.

[JamesMBligh]

Pagination parameters will be added to the Get Balances for Specific Accounts end point (and other specific account end points where needed).

[JamesMBligh]

Regarding @sandstoneau feedback regarding the meaning of the INTERNATIONAL enumeration value for phone numbers: the intent of this value is to indicate a specific number that can be used to contact the customer when they are overseas. A description to this effect will be added to the enumeration object.

[JamesMBligh]

Responding to the question from @anzbankau around the handling of an error condition. In general if a system availability issue has occurred then an error should be provided rather than a response with degraded information. There is no way for the client to know that the data is degraded without additional fields and it would be onerous for the client to build for all of the exception scenarios that could be identified. As a result, a service unavailability response should be provided.

In the specific example provided, however, the non-functional requirements potentially become important. While noting that NFRs are still in draft and undergoing review, they do include a data latency requirement that data should match the data available in other digital channels. In the situation where the current behaviour when an internal system fails is to present older balances via other digital channels this NFR would imply that it is acceptable to match this behaviour in the API response. The customer would experience a consistent experience regardless of the digital channel they accessed until service was restored. This can't be a formal response to this question until NFRs are settled of course.

[JamesMBligh]

Regarding versioning of APIs post version 1 being defined, which was asked about by @commbankoss:
a cadence for determining how changes to the standards post v1 is under development and will be put out for comment once the proposal has matured and been reviewed internally. In addition, a specific date to define v1 end points (effectively a standards lock down point) is planned to be decided.

[JamesMBligh]

Responses to some items of feedback that has been raised by @commbankoss is below. Other items raised are addressed in other posts where a similar issue was raised by multiple members of the community:

Security
This feedback has been forwarded to the InfoSec stream.

Pagination
The concerns raised have been addressed previously. The standards will maintain a direct access model but a cursor based model may be supported by data providers via link fields. This is a compromise that does not degrade the capability of the standards but still provides a path for a more performant implementation for many use cases. It is not agreed that the use of direct access is an "anti-pattern".

Bulk End Points
As stated previously, bulk end points will be retained and will be required for standards compliance. Concerns around performance will be addressed through the NFR definition process. The concern that bulk end points should be excluded until pagination issues are resolved are moot (see previous comment).

Closed accounts
Feedback on this issue have been addressed previously. Closed accounts are considered in scope with specific treatment provided in the NFR proposal to accommodate issues around data retention. Concerns around implementation timeframes for a specific date are best addressed with the ACCC.

IsOwned Field
It is expected that accounts that are not "owned" will be included in the regime where someone has been granted rights to someone else's account when acting as an agent, power of attorney. This is a common scenario. the isOwned flag was included based on previous feedback to accommodate these scenarios in the standard.

Detailed End Point
The detailed end point is a critical payload for most use cases. It will continue to be included in the standards for that reason. Also, previous feedback that rates need to be calculated has been addressed by providing the flexibility to represent base rates with conditions fully articulated (for instance base rate, bonus rates, etc can all be separately represented). As a result it is not believed that the need to calculate point prices is needed. If the data structure can be specifically improved (as opposed to simply removed from the standards) to address any remaining concerns that feedback would be very welcome.

Sensitive Data
Comments regarding the sensitivity of payee and customer data has been previously tabled and addressed. These entities will continue to be included in the data standards.

Pending Transactions
The feedback on inclusion of pending transactions has been previously provided and considered.

Transaction Type
The inclusion of transaction type was a compromise balancing a wide range of community feedback, including the implementation concerns of the Banks. The suggestion that the mapping load of individual Banks should be alleviated by requiring every data consumer to separately create mapping algorithms for every Bank does not appear to be an efficient position for the regime. If the mapping algorithm is simplified by including more transaction types this would be seriously considered, however.

Additional Feedback

• Product reference data feedback will be addressed separately in the issue targeted at Product Reference data.
• Non-functional requirements feedback will be reposted in the NFR issue and will be responded to there.
• Dashboard requirements will be passed to the ACCC.

[JamesMBligh]

Regarding the feedback from FinTech Australia regarding consistent implementation by data providers. This feedback is noted and is being consistently considered during the standards development process. This is a key driver for the definitions around mandatory vs optional fields and the preference for strongly typed structures where possible rather than freeform text. It is also the driver behind the creation of a standards conformance suite which is underway.

Feedback would be welcome where specific concerns regarding this issue arise.

[JamesMBligh]

In response to @NationalAustraliaBank, if the feedback regarding the three additional eligibility criteria appears to have been missed this was not the intention. Feedback of this nature was deferred until the ABA had responded to overall structural concerns for product reference data has been resolved. As this is now the case this feedback will be posted to the separate issue so that it will not be missed.

[JamesMBligh]

Regarding the lastUpdateTime field in the customer payload:

• For clarification, this field is expected to flag the last time that any of the presented data was updated and is an indication of how stale the data is likely to be. It was included due to direct feedback and will be retained in the payload
• It will be renamed to lastUpdated based on @anzbankau feedback

[JamesMBligh]

Regarding the clarification requested by @anzbankau regarding the difference between card accounts and actual cards attached to the account.

The intent of the accounts payload is to represent accounts and not cards. Many account types can have attached cards of varying types and there can often be multiple cards attached to one account. While this may change in the future the APIs defined currently do not include cards, only accounts.

As a result all account related data should be considered to be aggregated data at the account level and not at the level of individual cards.

[JamesMBligh]

With regard to feedback on balance data:

In response to previous feedback (and according to previous undertakings) a new end point to get the balance for a specific account will be included in the standards now that balance data has been removed from the account list payload. Balance data will be retained in the detailed payload, however, as this is only ever called in the context of a specific account and is already protected via a separate authorisation scope.

The simplified structure proposed by @NationalAustraliaBank will be considered and will be adopted if it is perceived that it will improve the usability of the payload without reducing data coverage.

[JamesMBligh]

The responses to feedback on individual fields is aggregated below:

• The delineation of whether mortgages are for owner occupied or investment property has not been included as it was not understood to be data that is currently digitally value. If this is high value data then it is recommended that it is specifically raised in the next round of feedback. As mortgage data is not expected to be included in the regime until 2020 there is time to debate this issue specifically
• Whether automatic credit card repayments are for the entire balance or minimum balance or some other amount is understood to be included in the payload through the separate fields specified. If there is a specific additional field required please specify in future rounds of feedback.
• Default status for customer will not be included in the payloads as it does not align with the concept of a consumer data right for the sharing of data owned by the customer. It is also not covered by the ACCC rules
• Director information for organisations is not included in the scope of the ACCC rules. In the context of the wider ecosystem it is also data that is better procured from ASIC rather than via the intermediary of a Bank. As company numbers are included in the payloads Director data can be separately obtained
• Based on previous discussions parties associated with accounts beyond the authorising person have not been included in the payloads. This applies to guarantors for accounts
• Details of relevant security property or other secured assets are not seen to be included in scope via the ACCC rules
• Details of the application for a specific instantiated account, while flagged in the Farrell report, are not currently in scope as defined by the ACCC rules
• legalName for an organisation will be made mandatory as suggested
• business name will be made an array that can be empty as suggested
• agentRole will be retained as a field and can be defaulted to an appropriate value defined by the data provider if the data isn’t currently captured
• Feedback on middleNames being mandatory: the field containing the array is mandatory although it is specifically commented that the array may be empty. Essentially this means it is structurally required but it is not expected that data will be provided in all instances. It is believed that this addresses the previously supplied feedback. This comment also applies to feedback regarding email addresses
• Regarding paymentDueAmount, there is no need to make paymentDueAmount optional. it can simply be set to the same value as minPaymentAmount if the amounts are the same

[JamesMBligh]

Feedback was received from multiple respondents requesting the inclusion of date or birth and gender for the customer record.

While these fields were originally included in the payloads they were removed in response to previous rounds of feedback, including feedback from consumer groups. This feedback covered various concerns from consumer understanding to the use of this data for alternate identification processes. The need to include these fields to support matching use cases is understood but the inclusion of this data will not be revisited for version 1 of the payload definitions.

The inclusion of this data in future revisions is a possibility but the concerns of the wider community would need to be addressed.

[JamesMBligh]

A number of responses related to the definition of mandatory, optional and conditional for individual fields in the payloads. This has been responded to a number of times in the past but, as the concerns continue to surface, it is clear that the standards need to specifically address these definitions. A section will therefore be included in the high level standards addressing these concepts.

This section will effectively articulate the statements in the list below, which is a position that has been previously articulated. There is no change from the current standards position in this list:

• The optionality of properties in the standards indicates a schema consistency statement
• A mandatory property must always be provided in a payload for it to be compliant with the schema. The absence of a mandatory property will make the payload non-compliant from a schema perspective
• An optional property, if left out of a payload, will not invalidate the schema compliance of that payload
• A conditional property is sometimes mandatory and sometimes optional depending on the status of other data fields in the payload. In certain, specified, circumstances the absence of the property will make the payload non-compliant from a schema perspective
• If the data provider holds data that appears in a payload, then it must be provided regardless of the optionality of the field. The requirement to transfer held data is derived from the fundamental right of the customer to share their data at their direction, not from the optionality classification of that data

[JamesMBligh]

Phew. I think that addresses all of the feedback. This thread will be reopened to allow the community to comment on any of the responses above in case the feedback has been misunderstood or in case clarification is required.

Friday COB this thread will then be closed and a new thread opened.

-JB-

[WestpacOpenBanking]

Direct Debits

If authorisations are to be derived using analytics under the given interpretation of 4.17 c) i) then we suggest that name be renamed to description and be used for a “Description of the authorised entity”. This will allow the field to be populated with narrative text or other relevant information in the majority of cases where it will not be possible to derive name analytically from transaction data.

Transaction Type

In agreement with @commbankoss, we ask that the proposed list of categories be given clear and mutually exclusive definitions in order to avoid consistency issues, allow us to commence mapping activity and determine the overall suitability of the proposed categories.

Mortgage Data

As part of the cadence for development of the standards post v1, we’d appreciate more detail on Data61’s intentions in accommodating mortgage accounts and products for Phase 2.

Additional minor things to fix

• The example in the HTTP Headers section still uses x-Correlation-Id despite the switch to x-fapi-interaction-id in the Request Headers table.
• The description for address in the AccountDetail object (as it was in the relevant decision) is missing.

[deboraelkin2]

Not sure, this is the right place to ask, but... What authorisation scope should be used for Direct Debit operations? Would it be

Detailed Bank Account Data - bank_detailed_accounts

?

[JamesMBligh]

In response to @WestpacOpenBanking:

• Change regarding naming of DD Authorisations is agreed. I'll add this to the list of changes
• Regarding mutually exclusive types, the seven proposed types seem pretty mutually exclusive apart from the OTHER type which is clearly a catchall and was specifically requested
• Regarding Mortgage data, as far as I am aware the APIs already accommodate Mortgage data both from an account and product representation perspective. While the implementation schedule is staggered we have attempted to address the full scope of the regime up front from a standards perspective
• Thanks for highlighting the minor fixes

-JB-

[JamesMBligh]

Hi @deboraelkin2 you are correct, the current nominated scope for DD Authorisations is bank_detailed_accounts

-JB-

[assem-ali]

A number of responses related to the definition of mandatory, optional and conditional for individual fields in the payloads. This has been responded to a number of times in the past but, as the concerns continue to surface, it is clear that the standards need to specifically address these definitions. A section will therefore be included in the high level standards addressing these concepts.

This section will effectively articulate the statements in the list below, which is a position that has been previously articulated. There is no change from the current standards position in this list:

• The optionality of properties in the standards indicates a schema consistency statement
• A mandatory property must always be provided in a payload for it to be compliant with the schema. The absence of a mandatory property will make the payload non-compliant from a schema perspective
• An optional property, if left out of a payload, will not invalidate the schema compliance of that payload
• A conditional property is sometimes mandatory and sometimes optional depending on the status of other data fields in the payload. In certain, specified, circumstances the absence of the property will make the payload non-compliant from a schema perspective
• If the data provider holds data that appears in a payload, then it must be provided regardless of the optionality of the field. The requirement to transfer held data is derived from the fundamental right of the customer to share their data at their direction, not from the optionality classification of that data

Hi James,
Just wondering when this clarification of optionality will be reflected in the standards?

[JamesMBligh]

Wow. I thought I’d locked this already :)

In response to your query @assem-li, it’s a good reminder. I thought I had already done this. I’ll do it shortly.

[JamesMBligh]

I've added the extended description of optionality and will now lock this thread.