Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Decision Proposal 044 - Draft Standards Feedback Cycle 3 #44
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:
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.
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.
Person Detail.phoneNumbers: Mandatory, At least one record is required
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.
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:
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?
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.1. Authorization scopes
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.
4. Banking APIs
4.1. Error Flows
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.
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
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.
4.3. Need of accountId with the unique transactionId
In transaction detail retrieval:
If transactions ids are unique do we need to pass an account ID?
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.
Requests for clarification
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:
Decision Proposal 044 - Draft Standards Feedback Cycle 3
Phone Number Purpose
The response to this suggests there is a valid use case for it
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.
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?
1. General Response to the Standards version 0.2
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.
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.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:
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.
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
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:
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
126.96.36.199 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.
188.8.131.52 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.
184.108.40.206 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.
220.127.116.11 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.
18.104.22.168 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.
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
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.
22.214.171.124 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.
5.1 Non-Functional Requirements (NFRs)
Commonwealth Bank is broadly supportive of the non-functional requirements proposed by Data61 but would seek clarification that:
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.
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.
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.
The following submission was received via email from FinTech Australia. It is provided here for transparency.
The following submission was received via email from FinTech Australia. It is provided here for transparency.
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.
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:
Fully elaborated example
Seek further clarity on feedback received
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)
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.
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.
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 ;).
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:
Note 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.
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.
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.
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.
Regarding versioning of APIs post version 1 being defined, which was asked about by @commbankoss:
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:
Bulk End Points
Detailed End Point
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.
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.
Regarding the lastUpdateTime field in the customer payload:
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.
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.
The responses to feedback on individual fields is aggregated below:
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.
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:
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.
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.
Additional minor things to fix
In response to @WestpacOpenBanking: