Decision Proposal 39 - Draft Standards #39
Comments
JamesMBligh
added
Category: API
JamesMBligh
changed the title
|
Could you please publish the source swagger.json used to generate the docs? The github has the result doc but not the definition itself? At the moment we are "estimating" the swagger definition so it would be good to get the direct one as soon as possible, even if it is in draft. In lieu of an official swagger.json we have published an approximated OpenAPI 3.0.x compatible version within our CDR Sandbox project: https://github.com/bizaio/cdr-sandbox/blob/develop/support/swagger.json We have verified compilation using the online Swagger editor (https://editor.swagger.io) although we admit we could clean up some general ordering. Once things are locked down we will do further cleanup. We will review changes following this thread and synchronise as quickly as possible as we work towards a development sandbox in support of the emerging CDR standard. |
|
Just a question on the Transaction responses as provided in the specification. In existing data delivery in Australia (via files), and in the UK Banking Spec, the transaction type is supplied with every transaction. This is a key field of a transaction, and the draft seems to have excluded this field. In the UK, the Transaction response must include either:
This seems to have missed the requirement stated in 5.3.2 - Transaction Data in the ACCC CDR Rules Framework
|
|
I have called out the same issue |
JamesMBligh
added
Status: Open For Feedback
|
By way of an intro to everyone, 86400 is a new entrant to the banking market and currently applying for an ADI license. We are supporters of Open Banking and its possible use cases to enhance customer experiences. The APIs that have been discussed in this open forum, and visible on the portal seem to be a very small subset of the APIs available in the UK model. The information returned in a Transaction query is lacking key elements that would create consumer value; Specifically the BankTransactionCode and MerchantDetails elements. As the specification is currently defined, the consumer of the data will need to parse the content to be able to categorise the transactions, and the quality is likely to be less than if the information was provided. Parsing the contents of the description is problematic as the format lacks any industry recognised structure. I would also advocate adding a BillerDetails element to structure BPAY payments - ie include the biller code, name and CRN. I also note the lack of support for Standing Orders. I had expected this to be front of mind as from a consumer perspective they need visibility to payments they have scheduled. The UK model appears quite robust in this regard... OBReadStandingOrder1. From a customer perspective who is looking to transfer their banking relationship to an new FI having the ability to access this information would make the process easier, and less error prone. Also missing is the concept of an Address Book. This is implemented in the UK model as OBReadBeneficiary. From a customer perspective having the ability to port their address book to a new provider creates a better experience. The masking applied to accounts and PANs is inconsistent with industry standards. The last 4 digits should be displayed in the clear - not 3 as currently defined. As others have noted the Extended Transaction data for NPP is incomplete. NPP transactions can be delivered as "Single Credit Transfers" (SCT) that have no defined service levels, or as an Overlay service that defines service levels (eg OSKO payments). The Services enumeration currently doesn't address this. Also missing from the NPP definition is "non-financial" transactions. These could include "request to pay" type messages that are to be delivered to a payer. They then have the ability to respond and send the funds to the Payee using the contents of the message. Transactions currently have defined states - PENDING or POSTED. Pending transactions normally relate to card based authorisations that are awaiting settlement. When settled the amounts may not match the values stored on the PENDING transaction and may carry FX rates and fees. These don't seem to be captured anywhere in the spec. Also missing is a discussion on when PENDING transactions expire. Typically this is within 3-5 business days of the authorisation request but varies by institution. This suggests that all calls to retrieve transactions will need to select at least 3-5 days of transactions.... unless all current PENDING transactions are returned if the selection end-date is the current date. Currently the input parameters only allow selection of transactions POSTED between the selected dates. |
|
One other question relating to transactions. Unlike how the Direct Debits or Balances schemas are working, where the same response is used for the Bulk call and the specific Account call, for transactions, the Bulk call and the specific account calls are using different responses - I'm excluding the Detailed call from this. All include accountId, But Get Transactions For Account has displayName and nickName, and doesn't flag if additional detail is available (isDetailAvailable). Get Bulk Transactions however, doesn't have displayName and nickName, but has the isDetailAvailable flag. Ideally, shouldn't these two calls just return the same information? I think they should both have the isDetailAvailable flag at the very least. I personally wouldn't have the account displayName and nickName in a transaction call. |
|
The single biggest issue facing this spec is the proper handling of pending and posted transactions, as they specifically relate to scheme authorisations. The ability to connect each pending transaction to a posted journal entry once the transaction has settled is crucial to the delivery of value to consumers. This is because it comes to bear upon the currently available funds of a customer at any given time. If a customer (or their nominee) isn't able to determine a customers' currently available funds, it throws out of sync the vast multitude of realtime/budgeting/value added calculations, services and potential notifications. In short, improper handling of account authorisations would render the spec almost useless. |
|
There is a mistake in the https://consumerdatastandardsaustralia.github.io/standards/#get-transactions-for-specific-accounts area. The 200 response points to AccountsBalancesResponse not (I assume) AccountTransactionsResponse |
|
There are no end-date parameters on the Transaction requests, so it isnt possible to retrieve transactions within a specified range, only from a date to today. Going back through the Decision 28, I couldn't see commentary suggesting that the end-date parameter was being removed. |
|
The extendedData element appears only returned when querying a specific transaction : accounts//transactions/. A call to accounts/transactions does not return this data element - instead it returns isDetailAvailable = true/false. It would be preferable to provide a parameter to control the return of the extendedData element in the following APIs: accounts//transactions Alternately always return the extendedData element |
|
@speedyps You are correct ... the end-date is no longer part of the filter.... although it is part of the UK standard. @JamesMBligh Was this intentionally removed? |
|
Hi All, some minimal response to some of the feedback to clarify. I don’t attempt to respond to all feedback here but there are some logistics to comment on... Swagger Discrepancies I have been reviewing since release and believe I have fixed these discrepancies. I suspect that some will still remain. Please note if something seems wrong. Also interested in whether the documentation is readable. Transactions Missing Payloads
-JB- |
|
@JamesMBligh The Swagger doesn't show the banking/payees end points although it is referenced in issue 32. Could I suggest that you provide a folder to record all of the final decisions - at present it requires trawling through all of the closed items to locate the pdf. |
|
The latest Swagger defines common field types "MaskedPANString" and MaskedAccountString. Both of these show the last 4 digits in clear. The Get Account Detail response shows the account being returned as MaskedAccountNumber with text indicating the last 3 digits are in the clear. This appears to be an error. When details are returned the Account Number should be returned in the clear. ie change the name from "maskedNumber" to "accountNumber" and set the type to String. Consider removing the MaskedAccountNumber type completely as it is conflicting with the common type "MaskedAccountString". |
|
When accountNumber is returned in the clear (see previous comment) guidance should be provided on the formatting to include BSB and Account. Specific reference needs to be made to handling 5 digit BSB's (ie unconditionally format as a 6 digit number followed by a separator (- or /) followed by the account number (these also should have formatting rules (eg 9 digit numbers with leading zeroes). NPP Participants will be well aware of the problems free-form account numbers have caused. Alternately implement a BSBAccount type {"bsb":"12345", "accountNumber":"12345"} where leading zeroes don't need to be considered. |
|
Rule 5.3.2 requires the inclusion of "any identifier or categorisation of the transaction by the data holder (that is, debit, credit, fee, interest, etc.). This seems to be omitted from the Get Transactions and Get Transaction Details I had expected to see structures similar to the UK model : Either the BankTransactionCode (which is the ISO transaction code list), or ProprietaryBankTransactionCode, or both may be populated. Parsing the description to determine the transaction type is problematic due to the proprietary formatting of this field by FI's. |
|
Rule 5.3.2 should also cover the identification of Card based transactions using the AS2805 fields supplied in the message. The MerchantDetails structure as implemented in the UK model would satisfy this need. Populating the Merchant Name and Merchant Category Code from the AS2805 fields will deliver a more accurate result than attempting to parse the message and add considerable value to consumers of the API |
|
Virtually every use case of value to customers requires transactions and their detail. As transaction detail has to be requested individually, what would be one call to the transactions endpoint with readtransactionsdetail as the permission grant (UK model), could become 1001 calls where each transaction detail is pulled individually (Aus model). As soon as this approach is scaled for any number of customers/accounts it becomes completely unsustainable for data providers and data consumers alike. |
@JamesMBligh, not having the transaction types ie things like Interest, Withdrawal, Deposit, Transfer, Direct Debit, ATM, ACH, Dividends, Check etc is a step backwards from what is available now. This is a fundamental part of data delivery today (and has been for the last 20 years). I would strongly suggest that the transaction record include a Type field. My recommendation would be to use the UK Open Banking spec ProprietaryBankTransactionCode entry. This would then match existing functionality and allow providers to use their own internal codes (and optionally specify if they adhere to an existing standard) If we wanted to stretch that bit further (but it might incur too much work for providers), I would recommend including the BankTransactionCode as per the UK Open Banking spec, (mapped to ISO 20022). This would mean that all transactions will be being reported the same way across all providers. However, I accept that this is probably one step too far based on our current timelines. |
This sounds like "a good idea" and can be solved with an OpenAPI format definition on the strings in question.
I agree that transaction type records seem like a relevant component to add to the standard. With that said I oppose the idea of adopting a proprietary record set because it's "too hard" to adopt an ISO standard. Provider implementation difficulty shouldn't trump the use of open standards not to mention that data mappers are used heavily within organisations already (ie. it isn't particularly difficult). If ISO20022 meets the requirements it should be adopted. Without wanting to politicise this process I dare say that organisations will come up with a myriad of reasons why they won't be able to hit the proposed timeline. While some of these will be valid it seems to me that the mere fact this standard is coming about through legislation indicates implementation challenges are far outweighed by protectionist attitudes in the industry generally. Happy to be refuted on this but maybe this is best taken offline (or integrated with a helpful response) to avoid poisoning @JamesMBligh's thread.
I disagree, a mere listing of high level transaction data seems like a very common use case akin to the current typical transaction list within normal internet banking applications. With that said though I agree that making 1:N calls to obtain detailed information could represent a significant API scale demand. Perhaps the middle ground here is that GET /accounts/{accountId}/transactions could include a detailed=true parameter which determines whether the returned object is BasicTransaction or TransactionDetail. The challenge of this approach is that the response is now softly typed with an anyOf between the two. I'd also point out that anyOf was not supported until OpenAPI 3.0.x so this makes older implementations incompatible. At this stage I don't believe the standard declares a minimum OpenAPI version, perhaps it should? The alternate to the above would be the introduction of a GET /accounts/{accountId}/transactions/detailed or GET /accounts/{accountId}/transactions-detailed method which would allow hard response typing while still achieving the goal. I favour the /transactions/detailed approach as it allows further extension while facilitating load balancer based decisions. Of course such decisions are possible in the non nested approach but imply a pattern match (rather than a URI routing) which would add additional performance consideration. With regards to Product Categories, I'd highlight the standard is enforcing a set list of types without a catchall like OTHER_TYPE being available. With changes in financial products occurring on a regular basis it's quite possible new (potentially implementation specific) account types will exist and not having a way of communicating these within the standard will result in misrepresentation for these cases and/or somewhat unnecessary adoption of vendor specific variable overloading (which is supported but a bit excessive?). With regards to the Account schema. The explicit use of separate Balance return types lends itself to nastiness if it extends past the current three. While this may be driven by the UK standard it is likely the reason for this was because at the time OpenAPI 2.x (fka swagger) didn't support nested oneOf's. I believe OpenAPI 3.x has added this support allowing for more explicit oneOf on the three return types. Ie. The return variable can be "balance" with 3 different types. This could put a spanner in code generation libraries though so maybe we just accept that there will be if/else chains to determine what balance variable to read. With regards to scope names, it's pedantic but the traditional method of scope declaration is x:y:read/write which typically lends itself to trivial pattern matching during security evaluation. The scope names as defined now seem more human readable than machine readable and this will result in pick list hardwiring resulting in nested if/else during implementation. Finally, the use of POST's to supply an array of values (as is the case in POST /accounts/transactions & POST /accounts/direct-debits) isn't "normal" REST nomenclature. Typically such requests would be placed inside GET's with query strings although I acknowledge that doing so could introduce query string limitations and also loose typing as OpenAPI GET support of arrays in query strings isn't particularly nice. All that aside though it means that scope assessment is once again being hardwired in a way that disregards the method type in the process and so WAF's won't be able to do explicit filtering at the point of receive. I accept I haven't provided much of a suggestion here but I've always seen GET as read, POST as create and PUT as update. This breaks such typical conventions but perhaps I just need to "get over it". :-) |
|
@jh-a I totally agree. Access to the detail should be controlled by a scope/permission to allow the additional structures to be populated by the provider when processing the Get Transactions call. Forcing the consumer to make additional calls to Get Transaction Detail will significantly degrade the end-user experience, place unnecessary load on the provider and provides no additional security on the detail data. |
This implies multiple response types with the same http code (or sparsely populated detailed transaction objects which, quite frankly, "sucks"). This was considered and rejected in 2015 (OAI/OpenAPI-Specification#270) but an alternate has since become available via anyOf/oneOf/allOf in OpenAPI 3 (https://swagger.io/docs/specification/data-models/oneof-anyof-allof-not/). With that said, using scope/permissions as the discriminator, in my opinion, is a "bad idea" as it is now tying the security implementation to the data generation layer. Channeling the KISS principle security rules should be defined cleanly & separate from data generation. It is very common practice to separate these layers (in code and/or infra and/or department) as it means security audits have a far smaller evaluation surface and can be coupled with response filtering (ie. inside the WAF) away from the data generation side. I don't see any particular advantage over simply adding a boolean "enable detail" parameter or separate detailed list call which, assuming OpenAPI 3 is the minimum expectation, can be facilitated with a oneOf wrapper on the transaction data. This approach could be trivially inspected at the security layer against the token permissions while keeping the data generation layer cleanly defined based on the input parameters. |
I agree with @perlboy on this. I think my preference would be for a flag to say enable detail, as that feels slightly cleaner. |
|
@speedyps Works for me... a flag to control what is generated, and scope to ensure the caller is authorised to set the flag. |
|
Hi, |
|
To supplement on my colleague @DDobbing 's feedback above, from SWIFT’s perspective, we highly recommend the consideration of using ISO20022 message elements and components where applicable. Another point I want to make is to make sure the design of payload has considered both from the lenses of consumer client and corporate client. For instance, the response data’s structure and completeness are more important for reconciliation purpose from a corporate client’s perspective. A few more suggestion: |
|
Our first feedback is to say well done on reaching the milestone of a first draft for Open Banking! Below is our feedback on the first draft. Please note, given this is the first draft, we have sought feedback from a wider group of internal stakeholders, so some feedback will be on earlier decision proposals. We felt it was important to include this feedback, as it relates to complexity in implementation. HTTP Headers (MGL-1) We support the requirement to return a minimum of set of standard HTTP response headers, to ensure strong security amongst all data holders. A good starting point for these headers is https://www.owasp.org/index.php/OWASP_Secure_Headers_Project#tab=Headers URI Structure (MGL-2) Although discussed in an earlier decision proposal, feedback from our engineers is a strong preference to avoid naming collisions in the URI structure. As an example: GET …/accounts/{id} Returns the detail of a specific account The second API makes it difficult, as you need to ensure there is no {id} = transactions. It would be preferable to have this as GET ../transactions Pagination (MGL-3) We don't support making the following attributes mandatory: page, last, totalRecords, totalPages. Having to implement page, last, totalRecords, totalPages requires architectural changes, and will have an impact on performance. Given the timeframe of 1st July 2019, this would be difficult to accommodate. Security (MGL-4) As noted in our previous feedback, we do not support using MTLS. See our original comment for rationale and preferred alternative. Get Accounts (MGL-5) (MGL-5.1) Could a more detailed description be given for the providerType field? It is not clear what we should provide for this field. Perhaps a more descriptive field name could also be given? (MGL-5.2) Our preference would be for balances to be removed from this API, and only be included in the balances API. The rationale for this is: Get Bulk Balances (MGL-6) We have concerns about being able to meet API principle #9 (APIs are performant), particularly where the consumer may have thousands of accounts (e.g. a business, accountant, or financial adviser). For July 1 2019, we would like to see this made optional, and give time to explore if there are any better patterns for handling bulk balances. If bulk is required, a data consumer can still retrieve all accounts, and then retrieve balances for a set of accounts at a time. Get Bulk Transactions (MGL-7) We have concerns about being able to meet API principle #9 (APIs are performant), particularly where the consumer may have thousands of accounts (e.g. a business, accountant, or financial adviser). For July 1 2019, we would like to see this made optional, and give time to explore if there are any better patterns for handling bulk transactions. If bulk is required, a data consumer can still retrieve all accounts, and then retrieve transactions for a set of accounts at a time. Get Direct Debits (MGL-8) As has been communicated prior, direct debit authorisations are not held by banks, so this API cannot technically be implemented. Our recommendation is that this API is flagged in some way, so that all participants are aware that it is not feasible to implement. Get Products (MGL-9)
|
|
In addition to earlier feedback, we have the following additional comments. +1 on use of cursor based pagination. Perhaps with examples of bulk API call with return of multiple account transactions with attention to pagination. Perhaps include additional customer$type of "delegate" to accommodate a delegated user who has access to an account permitted by the account owner, e.g. financial advisers. May be CreditCardAccountType needs a "balance$type"? Both Loan and Credit Card Accounts should have an "autoInstallment" Boolean to indicate whether the bank will automatically direct debit the customer to pay the minimum amount type. There should be an Investment account type (for specificAccount$type) supporting brokerage, annuity, pre-tax retirement and post-tax retirement holding types and transactions to support personal financial management or investment advisor applications. |
Direct DebitsRepeating our comment on #29:
We understand that the current position of Data61 is that as the ACCC has this specifically in scope, then it will remain in the API. We consider this position bizarre. Having an endpoint that does nothing makes no sense. We hope the ACCC sees sense. SecurityThere is no mention about the user opting into the sharing of specific accounts. Our expectation is that the PSU will be able to consent explicitly to which accounts are available to the data consumer (as per UK). Get Transaction DetailJust a clarification on the What's the intent of this structure? It appears that we are redirecting one string field to another. We propose the As identified by others, need support for Pending transactionsThere have been several mentions of pending transactions. These are not a thing from the perspective of a core banking system. They do not appear as a transaction on the account or the general ledger or a customer's statement. Pending transactions, which we call holds, are an entirely separate concept that can change the available balance of an account. They can be deleted, and they can auto-expire. Including holds, if in scope, should be a distinct endpoint to the transaction endpoints. Get ProductsThe
Giving a specific meaning to We would also re-iterate the need we stated here that discounts can be applied to customers, not just to products and accounts. This is a form of bundling. An example of this might be a regular customer gets $100 per month of waived transaction fees, rolled up across all of their accounts; where a high-value customer might get $200 per month of waived transaction fees. The Also a swagger nitpick - example code includes PaginationOthers have suggested cursor based pagination is preferred. We have no strong preference either way, and will support either, but not both. |
|
Westpac has the following additional comments Endpoint versioning and SwaggerThe current proposed versioning strategy is problematic when viewed in regard of swagger and automated tools for development (including automated code generation), quality assurance, operations and so on. In particular, there is no standardized way for swagger 2.0 to accommodate endpoint versioning with the proposed header negotiation – it can only expose all endpoints and fields for an API. We note that the versioning proposal was only able to be commented on by one bank and two individuals, and we feel that this issue needs to be revisited with wider input. We strongly suggest a block versioning split by authenticated/unauthenticated endpoints and by industry (including a separate version for common endpoints) in alignment with the UK. This approach will support the development needs of both consumers and holders by allowing them to continue to use off-the-shelf and standardized development tools and welcome further discussion on the issue. Other remarks on the Swagger specification
Sensitive PII data includedA number of endpoints, including the customer endpoints, the account detail endpoint, the payee endpoints and the transaction endpoints include sensitive data. We have concerns with sharing sensitive data without masking/hashing. We also note that the sensitive data shared may not be the data of the party who gave consent to share it. Sharing such information at scale puts at risk sensitive information of both customers and non-customers. BillerCodeWe are able to provide billerCode for payees. For transactions, the billerCode is part of the payment instruction which is not always possible to link to the transaction and may or may not be held by us. Transaction CodesTransaction codes in Australia depend on the payment type and are often proprietary (with less standardization than in the UK). We think that the most value to data consumers will be provided by providing an appropriate ISO 20022 code, but that doing so requires considerable mapping activity to occur. This would also be the case with a less complex scheme with fewer transaction types. For pragmatic reasons around the July 19 deadline and build complexity we suggest that codes are added to a later version of the standard. Data quality and data entryData quality issues are common with customer entered information. For example, customers might accidentally transpose or misspell names or may not understand the difference between a business name and a trading name and enter those fields incorrectly. We suggest that the descriptions of person, organisation and payee endpoints reflect how data has been collected and that it is subject to customer error. This would facilitate transparency around the accuracy obligations under the proposed Consumer Data Right Privacy Safeguard 11. Minor inconsistencies between draft standard and decision proposalsIn addition to those noted in our previous response, we have spotted the following inconsistencies between the draft standard and the decision proposals:
We agree with @anzbankau’s comments on the transaction, product and account endpoints, on common schemas and their general comments section. In particular, we note that the comment about the inconsistent use of an amount object for storing amounts and currencies. We suggest alignment with the UK and consistency. |
SummaryNAB welcomes the opportunity to respond to the 2 November 2018 Working Draft of the CDR/Open Banking Standards. Summary of our feedback:
Related feedbackThis response builds on NAB’s extensive contributions to the public policy debate on Open Banking. These include:
Sensitive InformationIn all of NAB’s interactions regarding the development of the CDR we have emphasised that safety and security of customer data is absolutely paramount. NAB continues to have serious concerns regarding the security implications of some aspects of the framework. This includes the sharing of sensitive information including Personally Identifiable Information (PII) and information that supports banking identity verification, such as mobile numbers and email addresses. It also includes customer sensitive transaction and payee data. NAB objects to the inclusion of customers' personal information as there are significant security risks associated with the sharing of such a level of confidential data. Given that KYC data is excluded in Phase 1 and customers will not be able to switch providers via the CDR alone, NAB does not consider there is an appropriate use-case for the data. There is also a strong argument that any personal information can be supplied by the customer to the data recipient directly. SecurityThere are significant security risks associated with the sharing of confidential data and therefore security should be our top priority as part of the Open Banking scheme. NAB welcomes the kick-start of the industry security forums but we strongly recommend Data61 dedicate more resources to carefully and dutifully analyse abuse-cases and design controls in collaboration with the industry to achieve a high security standard. We have identified a number of security gaps that require further analysis and inclusion in the Standards, as follows:
The definition of these and other security gaps are essential to complete the solution's blueprint. Where these matters remain uncertain, it limits the ability of data holders to build a solution and has the potential to add delays and risks to the process. Phasing of scopeWe strongly recommend focusing on a smaller set of Minimum Viable Product (MVP) APIs for Phase 1 rather than attempting such an ambitious scope. It will be a major accomplishment to have the system go live by July 1st 2019 regardless of the number of APIs that are present in the scheme. Instead we should focus on de-risking the implementation by focusing our attention on the non-functional aspects of the scheme. We highly recommend following an Agile or Iterative methodology as this allows us to learn and adapt as we uncover the finer intricacies of what makes for a successful and secure system. Now that we have visibility of the data scope which consists of 17 APIs we are confident that the timelines are unrealistic, especially given the fact that industry testing will need to start well before July 1st 2019. We also are cognisant that the directory and administration APIs are unclear and will also require significant data holder implementation effort. As a start, we propose the following APIs be removed from the MVP scope. These APIs either provide the same data as other APIs, expose sensitive data, or we as data holders do not have the data available. We also propose that a plan is developed to include a review and updates to the Standards based on the planned phasing i.e. Phase 1, 2 and 3. Rather than review the current published Standards as the final end state version, NAB considers that there should be an opportunity to review and revise the Standards after each phase implementation in order to improve them for the next phase. Feedback on the processWe commend the progress made thus far, the openness of the process and the pace at which the various industry bodies are working in parallel. There are however, fundamental gaps:
General standards feedbackWe have previously given feedback via DP30 that the definition of mandatory vs. optional vs. conditional for each field/object was too ambiguous e.g. sometimes within the standard Optional seemed to indicate a provider choice. To minimise confusion and interpretation whilst implementing the APIs we would like to see the revised version of the Standards clearly distinguish:
Transactions APIsThe following feedback relates to the transactions APIs:
Overall Detailed transaction remittance information within transaction data APIs allows data recipients to infer and correlate information about our customers, their behaviour and lifestyle patterns (e.g. data about hospital visits and specialist treatments and conversations via NPP detailed and instant remittance information). The inclusion of this information may not be apparent to customers when giving consent and is irrevocable once granted. Customers may not be aware of the possibilities of how this data may be used in ways which they did not intend. Therefore, we recommend additional and more granular authorisation scopes for transaction data as per the below list:
Query Parameters The inclusion of complex query parameters such as transaction amount and free text searches across vast data sets and unbounded timescales is resource intensive for data holders. We recommend reducing the MVP scope and making these query parameters optional. Description We believe the definition "The transaction description as applied by the financial institution." is too broad and can be interpreted in many different ways. We believe this should be detailed further with some examples given. Direct Debits APIsThe following feedback relates to the direct debits APIs:
As previously mentioned in DP29, banks are not the data holders for direct debit authorisations which are debited from their customers' accounts. NAB strongly objects to the proposed approach which is a workaround to derive the data from the already processed direct debits. This will not be a trivial exercise, could lead to inconsistencies across implementations and exposes incomplete and misleading data. We also question whether this would deliver the intended user experience, particularly in the use case of account portability, as key data is missing e.g. frequency, amount per debit, expiry date. We also note that in Phase 1 account portability within the CDR will not be possible given KYC data is excluded. Get Payee DetailAs previously mentioned above and in DP32, the API payload contains the personal information of other parties. NAB strongly objects to the inclusion of data that belongs to other people or organisations without their explicit consent. The transfer of this data would effectively involve the transfer of personal information where the individual to whom it relates has not explicitly consented to its transfer. In addition and as noted above, in the absence of a use-case for data portability in Phase 1 of the CDR we do not agree or endorse that this data should be included. DomesticPayeeType - bsb and accountNumber We note that the bsb and accountNumber for the customer's payee are not masked whereas we do expect the customer's account number and BSB to be masked. We believe this is inconsistent and masking should also apply to the payee's account number and BSB. DomesticPayeeType - payId The name field should not be included in the Standards. This field is mandatory and is defined as "The name assigned to the PayID by the owner of the PayID." However, this is not data required to make an NPP PayID payment nor is it always held or stored by the data holder. There are other ways to access this data held by the NPP PayID Central Addressing Service. The identifier field is a payee's personal information e.g. mobile number, email address. The identifier is not the customer's data and the data holder does not have consent from the payee to share this data. The payee may not want the customer to share their personal information with a third party. The payee may have provided their PayID to the customer with the expectation that it would only be used to make a payment via the customer's banking channel. Common Schemasaddress within AccountDetail Similar to our other concerns regarding the inclusion of a customer's personal or sensitive information within the payloads, we object to the inclusion of the correspondence address information within the Account Detail payload. The correspondence address is considered PII and is particularly sensitive, especially if this potentially reveals the location in which the bank will send out physical plastic cards. Also, we believe it is not intuitive for a customer that their detailed account information also includes their address. balance$type and associated structures We believe the way Balance and Limit are represented are overly complex and suggest this should be be simplified. We believe the current proposal creates the need for more complex processing rules for data holders and data recipients than is necessary. 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: AccountBalance Properties AccountLimit Properties ProductCategory While we can work with the enumerations outlined in the standard, we think it’s easier and at times more accurate to remove the Business and Personal separation for this classification and use eligibility criteria to determine whether available to businesses or individuals or both for most product types. We also believe the Foreign Currency options can be treated as Features within existing product categories rather than mandating them as their own categories. Given the above, we propose a simpler list that looks like the below.
maskedNumber This definition of masking conflicts with the definition in the standards section under "Common Field Types". Also in the standards section there are two masked data types, one for credit cards and one for other account numbers, whereas within the Accounts payload, only one type is used for both. CreditCardAccountType We don’t understand the difference between minPaymentAmount and paymentDueAmount and this should be further detailed in the description. They appear to be the same field. LoanAccountType LoanEndDate, nextInstalmentDate, minInstalmentAmount and repaymentFrequency do not apply to most Overdraft type products so recommend they should be optional and not mandatory openStatus (missing) We note that openStatus is missing in the response. This has previously been agreed to be included but has not made it into this version. providerType / productName We note the previous change of providerType to productName in this schema has been rolled back. We assume this is an oversight as this was fixed in final published versions of DP27 and DP31. isNegotiable As previously stated, we do not support inclusion of a field called isNegotiable, particularly as described. We propose the following replacement name and description:
Product & Account ComponentsOverall We are concerned that the split of the Account and Product Components into different groups / enumerations (for example Product Feature Types / Account Feature Types, but extends also to Fee Types, Discount Types and Rate Types) will lead to these diverging over time and this does not seem necessary. This is already happening with the ESTABLISHMENT fee type being available as an option in Product Fee but missing from Account Fee. We assume this is an oversight, but propose they are all merged to remove future / unnecessary anomalies or confusion. If these are to stay split, what controls will be in place to ensure they remain consistent? Feedback throughout is combined in the interest of not repeating ourselves. Rate Type Feedback As per our feedback on DP30 the modelling of interest rates is insufficient. The suggestion that complications for differences in rates should all be covered in the additionalValue field can be implemented by NAB but is not easily machine-readable. Examples of the sort of information that would need to be placed in the additionalValue field is outlined in the links below that we publish today. Note that the additionalValue field will need to include information about lending purpose, repayment type and fixed term in the home loan examples. https://www.nab.com.au/personal/interest-rates-fees-and-charges/interest-rates-for-home-lending Product Feature Types / Account Feature Types We recommend the inclusion of the additional Feature Types listed below:
Product Fee Types / Account Fee Types We recommend the removal of the fee types listed below from the enumeration as they are specific fee names, not fee types (i.e. these should be listed fees within the Fee name field mainly classified as OTHER_EVENT):
Product Discount Types / Account Discount Types We recommend the inclusion of the additional Discount Types listed below:
Product Deposit Rate Types / Account Deposit Rate Types As per previous feedback, we recommend the inclusion of the additional Deposit Rate Types listed below:
Product Eligibility Types We recommend the inclusion of a type to indicate that a product is available to an individual / natural person. Common (customer) APIsOverall As explained above and in DP26, we strongly believe that PII that is currently used for the purposes of identity verification, password recovery or multi-factor authentication should not be shared with data recipients under any condition. lastUpdateTime 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. Given the uncertainty regarding the intent and accuracy of the field, we recommend the field to be removed or be made optional. firstName, middleNames, prefix These fields should be optional as they may not apply to all customers. isPreferred (Phone) This field should be optional as it is for email. No preference may have been captured so can not be inferred. Also, some customers may have requested (as a preference) not to be contacted by phone, so provision of any phone number as a preferred contact number would be inconsistent with previous customer preferences. occupationCode NAB considers that this field should not be included within the customer payload, as it is likely to be inaccurate (i.e. it may be out of date) and that it is sensitive customer information for an individual. In addition, we note that this field was not specifically referred to within the Designation Instrument or Rules Framework. abn, acn, isACNCregistered, industryCode, organisationType, registeredCountry, establishmentDate This data was not specifically requested within the Designation Instrument or Rules Framework so we do not believe it should be included within the customer payload. phoneNumbers, emailAddresses NAB has previously provided detailed feedback regarding our concerns with respect to sharing sensitive PII data. NAB strongly believes this data should not be included in the payloads as it increases the risk of identity takeover in the event of a breach. physicalAddresses As above, NAB has serious concerns with sharing sensitive PII data via payloads. We also note that this data was not specifically requested within the Designation Instrument or Rules Framework. |
|
Commonwealth Bank is supportive of the principles that have been applied to developing the Consumer Data Standards (Standards). A summary of our recommendations are below, and have attached a document containing our detailed analysis. StandardsWith respect to the standards, Commonwealth Bank is broadly supportive of the recommendations associated with the versioning of APIs, HTTP response code definitions, and payload extensibility. Further clarity is required around the definition of fields marked as mandatory or optional. SecurityIn relation to information security, Commonwealth Bank is concerned that important topics are yet to be addressed. Given the relationship between the API Standards and Security Standards, it is difficult for us to provide support around a number of topics until more clarity is provided on security. Banking APIsCommonwealth Bank is broadly supportive of the majority of the API definitions relating to accounts. Our primary concerns are around the scope of included data. We believe the current coarse-grained approach may lead to unnecessary over-sharing of sensitive data. For particular aspects of the standard, such as the implementation of individualised account objects and bulk data, we have technical concerns around the complexity which will result in a protracted delivery timeline. As such we suggest that they are pushed to a further version of the standards to accommodate this. Common APIsCommonwealth Bank are not supportive of the current definition of the customer payload. We believe description and use cases of this API are not fit for purpose and could again lead to inadvertent data leakage. We recommend the deprecation of this API in favour of an amendment to the accounts payload, and use of the OAuth 2.0 UserInfo service. Additional Recommendations
|
|
BPAY is Australia’s leading payments scheme and operates for the benefit of more than 150 member financial institutions. In February 2018, the BPAY Group launched its new payment product, Osko by BPAY®, offered by more than 60 financial institutions including the four major banks. Osko® is the first product available on the NPP. Feedback from BPAY Group, is as follows: ExtendedTransactionData: Each overlay service for the NPP can define its own transaction data elements (eg: X2P1 may contain different data elements to X2P2). The ExtendedTransactionData element does not appear to provide the capability to identify which fields belong to which service type. Suggest that extension$type should be an object that is specific to the overlay service used, containing the data elements for that service. For X2P1.01, the extension data should include the following fields to support the Osko product:
Note that endToEndId and purposeCode are not currently included as part of the extension data. For X2P2.01 and X2P3.01, we would anticipate that the extension data for each will include a different set of fields to those used for X2P1.01. The data structures used for ExtendedTransactionData should support these different field sets for the different transaction types. ExtendedTransactionData:payee has description: “Label of target PayID. Mandatory for an outbound payment”. Note that a transaction can be addressed to a BSB-Account (which is not a PayID). Would anticipate that the user entered account name would be used in this case, suggest description should be updated for clarity , eg: “the name assigned to the BSB/Account Number or PayID (by the owner of the PayID)”. ExtendedTransactionData: should also have data element for PayeePayId (in addition to the payee field used for the name), that is populated in case where a PayID is used to address the transaction. This should also have a supporting field that identifies the type of the PayID used (PayeeAccount$Type). PayeeAccount$Type enumeration: the enumeration values should be aligned with the NPP descriptions for aliases: email, telephone, ABN, organisation identifier. Currently listed in spec as: email, mobile, org_number, org_name. ExtendedTransactionData:Service enumeration: the valid value is currently listed as “X2P1.01”. This should be lowercase “x2p1.01” to correspond with the NPP definition. TransactionDetail: does not provide any fields that allow identification of the transaction type, other than if it is an NPP transaction. Should have capability to identify type of transaction for all types, eg: Direct Entry, BPAY Payment, Osko Payment, Osko Request, etc. Also, TransactionDetail also does not contain any elements that allow identification of the payee for these transaction types (eg: BSB-Account, BPAY Biller Code & CRN). Consideration should be given to adding support for additional transaction types and their corresponding data elements to TransactionDetail (or potentially ExtendedTransactionData as extensionTypes). TransactionBasic:Description & TransactionDetail:Description: suggest further clarifying the expectations around what will be in the Description field, and its potential relationship with other description fields that exist (eg: ExtendedTransactionData:ExtendedDescription). For example, for an NPP transaction is the expectation that these fields will both contain the same value? |
|
American Express Australia has the following feedback in relation to the draft standards in addition to the questions and comments raised during the working group sessions. General Questions: To assist with resource and capacity planning will there be a draft character limits placed on each field or are all fields assumed to have no fixed character limit? Transactions Foreign Exchange rate used for a transaction is an important data element that is not currently included in the Standard. American Express's position is that this should be included as a transaction level data element. For transactions that are not Institution to Institution but follow a merchant to consumer model the Standard should clearly define which data element should carry the merchant name and details for consistency across users Some edge cases for certain transactions types occur, in situations where charges are presented late (up to 6 months) or disputed transactions are suspended on a customers account certain mis-match in date and time of transaction type (Pending/Posted) may occur. These should be added to the test cases when testing the robustness of the Standard after the next draft release. Account The data holder will attempt to mask any PII known to be held when being passed however for customer input fields such as NickName the Standard should specify that once consent is obtained the data will be passed as is without further investigation or masking if customers choose to enter PII in fields where they should not. MaskedAccountNumber field should be increased to the last 5 digits. Last 3 digits for American Express accounts are very common so last 4 digits would be the minimum to differentiate between cards held by a single consumer with American Expresses preference to display last 5 digits. ProviderType element Standard should include Charge Card as distinct from CreditCard. balance$type element Standard should include Charge Card as distinct from CreditCard. Product The Fee field should have an additional field to determine the frequency with which the fee type is charged (Monthly, Annually etc.) ProductDiscount - Open question on if this element should be used to pass data on non dollar discounts and acquisition offers such as points bonuses etc. ProductFeature The valid list of types documented only cover a small subset of features available, an additional field should be defined to enhance the information passed in this field. American Express hopes to continue to provide feedback and participation in the sessions and looks forward to the next revision of these standards. |
|
Ultradata would like to thank Data61 for the open process associated with the creation of the Data Standards and has the following feedback in relation to the draft CDR standards. Consent / Authentication / Authorisation
Scheduled payments / Standing orders
Direct Debits
Transactional Data
Change cadence, obsolescence, versioning etc
Error Handling
Organisation v customer v agent
|
JamesMBligh
added
Status: Feedback Period Closed
|
Thanks for the extensive feedback. The feedback period was extended due to specific requests. If there is outstanding feedback please send it via email to [email protected]. Any email feedback will be posted on this thread for transparency. The planned steps from here are as follows:
-JB- |
ConsumerDataStandardsAustralia
locked as resolved and limited conversation to collaborators
|
Customer Owned Banking Association (COBA) submission received via email to the CDR mail box 22 November 2018 |
|
Australian Retail Credit Association (ARCA) submission received via email to the CDR mailbox 22 November 2018. |
|
SunTec Business Solutions submission received via email to the CDR mailbox 22 November 2018. |
|
illion submission received via email to the CDR mailbox 22 November 2018. |
|
Finder submission received via email to the CDR mailbox 22 November 2018. |
|
Visa submission received via email to the CDR mailbox 22 November 2018. |
|
AGL submission received via email to CDR mailbox 26 November 2018. |
|
Law Council of Australia submission received via email to CDR mailbox 22 November As of 9am 27 November, this is all submissions received via the CDR mailbox. |
|
Apologies everyone - two submissions were missed in the CDR mail box. Uploading now. Submission 031 from Xero Ltd received via email to CDR mailbox 23 November 2018. |
|
Submission 033 from CommsAlliance received via email to CDR mailbox 23 November 2018. 033_181123_CA Submission Draft API Standards_SUBMITTED (1).pdf |
|
Hi everyone. I was hoping to get this out over the weekend but the quantity and, more importantly, quality of the feedback that was provided meant that it took a bit longer to process and get reviewed than I anticipated. Please find attached here a PDF containing a summary of the feedback received that has also be categorised. The feedback that was policy or security related has been passed on to the relevant teams. The feedback that was related to the API standards has either been accepted or responded to. I will now open two new issues. One specifically for product reference data - as this is clearly an area that needs specific focus - and one for comments against the standards as a whole. Comments or requests for clarification can be posted there. -JB- |
JamesMBligh
added
Status: Decision Made
|
FinTech Australia was given an extension to the 23 November deadline. Submission 034 attached, received via email to the CDR mailbox Friday 7 December 2018. |
and others
This thread is for feedback on the full 2 November working draft. Overarching feedback on the draft can be made here, and complete responses to the draft in .doc format can also be uploaded.
Updated 11 November 2018
Thanks to everyone who is already adding feedback to this thread. With organisations having three weeks to respond to the working draft in full, we're going to hold off on deeply engaging with this thread until after the 23rd November. We are watching and monitoring and absorbing feedback, so please do keep it coming.
Cheers,
Ellen
The text was updated successfully, but these errors were encountered: