Closed JamesMBligh closed 5 years ago
speedyps
commented
5 years ago 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
commented
5 years ago Thanks @speedyps. This was an oversight. FIxed now.
-JB-
speedyps
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago Balance.DepositBalance & LendingBalance Types The DepositBalance & LendingBalance types seem to have lost their Descriptions in version 0.2.0.
deboraelkin2
commented
5 years ago 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
commented
5 years ago The Get Transactions APIs accept start-time and end-time as optional query parameters, and their default values are defined as:
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:
sachi-d
commented
5 years ago Hi all,
Please find the following feedback from Financial Solutions team at WSO2.
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?
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?)
Can multiple authorization scopes be used in a single request?
In Information Security Profile, Section 5.1,
Are these two equal? The concern was raised due to different values present in the sample.
In data retrieval calls for specific accounts:
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.
The Get Transactions for Account call, is presumably used to retrieve transactions of a single account
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.
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.
In transaction detail retrieval:
If transactions ids are unique do we need to pass an account ID?
Cheers, Sachithra Dangalla, WSO2 Financial Solutions Team
WestpacOpenBanking
commented
5 years ago 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.
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.
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:
AmexAUopenbanking
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
Commonwealth Bank recommends that the legalName field is made mandatory, Commonwealth Bank is required to obtain this information through a standard on-boarding process.
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.
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.
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.
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.
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.
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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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.
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:
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 accountAccountBalance 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.
{
"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"
}
}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
commented
5 years ago Clarification
Feedback GET /common/customer
JamesMBligh
commented
5 years ago 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
commented
5 years ago The descriptions for Balance.DepositBalance & LendingBalance Types will be restored.
JamesMBligh
commented
5 years ago Pagination parameters will be added to the Get Balances for Specific Accounts end point (and other specific account end points where needed).
JamesMBligh
commented
5 years ago Get Transactions end-time description will be amended to say “minus” 90 days. Based on feedback from @commbankoss the 100 days will be changed to 90 days to approximately match 3 months.
JamesMBligh
commented
5 years ago x-Correlation-Id was included before work on the InfoSec stream began. Now that the FAPI profile is being adopted this header is being replaced with x-fapi-interaction-id which performs the same function.
x-Correlation-Id is now removed from the standards and has been replaced by x-fapi-interaction-id.
In response to the question from @commbankoss, yes this header will be added to response as well.
JamesMBligh
commented
5 years ago With regard to versioning, it is not yet known what kind of changes will result in the high level standards changing. Accommodation has been made for this event, however, as it is inevitable. At this stage it is anticipated that this is for major overhauls of the standards as opposed to changes in end points and payloads.
JamesMBligh
commented
5 years ago Regarding the comments on security provided by @sachi-d: Multiple scopes are expected to be provided. The additional, more detailed, question should be tabled within the InfoSec stream.
JamesMBligh
commented
5 years ago Regarding comments around improved error flows, this is accepted feedback. Improvements to the documentation for error flows is planned but will likely not be immediate.
JamesMBligh
commented
5 years ago Regarding the question from @sachi-d as to why an end point for getting a single account and an array of accounts are both included: While both use case can be achieved using the POST it is expected that the POST query to obtain multiple accounts would be used less frequently and the GET end point would be preferable if only one account was sought as it is more cacheable and requires less code to execute.
JamesMBligh
commented
5 years ago Regarding the inclusion of the accountId in the transaction detail end point: It is not assumed that the transaction ID is globally unique. By including the account ID a data provider only needs to ensure uniqueness in the scope of a single account. This will simplify implementation for data holders that may not already have unique transaction IDs.
Also, this model ensures the context is explicitly maintained in the URI structure (which is prettier ;).
JamesMBligh
commented
5 years ago In response to the updated rules from the ACCC an additional decision proposal (or multiple) will be created to accommodate scheduled payments.
JamesMBligh
commented
5 years ago Regarding feedback from @WestpacOpenBanking regarding Direct Debit Authorisations:
Based on the full text of clause c) it is understood that the end points are ok as they are. The full rules text is:
c. authorisations on the account, including:
i. direct debit deductions, which will include, to the extent available:
- identifying information for the merchant or party that has
debited the account
- the amount the merchant or party has debited on each
occasion
- the date the merchant or party has debited the accountNote that this text refers explicitly to authorisations. The inclusion of direct debit deduction data is a recognition that Banks do not hold the authorisations as they do in other jurisdictions and have to infer the authorisations from executed direct debits instead.
JamesMBligh
commented
5 years ago Sample data for productName, nickName and displayName will be added to the documentation in due course. In general the goal is to improve the sample data across the board but this will take time.
JamesMBligh
commented
5 years ago Regarding the request for clarification from @WestpacOpenBanking regarding x-fapi-customer-ip-address: yes, the “device headers” in the NFR document is x-fapi-customer-ip-address. If additional headers are required for pass through (such as client user agent, etc) then this feedback should be provided to the InfoSec stream.
JamesMBligh
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago 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
JamesMBligh
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago Regarding the lastUpdateTime field in the customer payload:
JamesMBligh
commented
5 years ago 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
commented
5 years ago 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
commented
5 years ago The responses to feedback on individual fields is aggregated below:
JamesMBligh
commented
5 years ago 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
commented
5 years ago 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:
JamesMBligh
commented
5 years ago 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
commented
5 years ago 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.
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.
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.
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-