Below is a summary of all feedback on v2.0.0-rc1 received from standards users and wider industry engagement.
Feedback collected from Tuesday 12 November 2019 until 10 December 2019.
Contributor | Category | Feedback | Response |
|---|---|---|---|
Paymark | Payments Initiation API | Addition of refund API links to the Payment initiation V2.0 release candidate:
| Refunds are not currently an agreed part of the scope for v2.0: It should be noted that in the v2.0 standard - Third Parties are be able to initiate a refund to a Customer via these steps:
Note that the existing v2.0 (and v1.0) standards rely on push payments initiated by the Customer's Bank. If we were to re-utilise the push payments system for refunds - then a refund must be initiated by the Merchant's Bank. Your feedback on future functionality will be incorporated into the discussions informing the scope for pipeline activities. |
BNZ | Account types | We would like to see what it would take to loosen the limitation of the accounts to only BECS identifiable accounts to include scheme card formats Limiting the types of transactions / accounts to be able to be queried to non credit card accounts may make the Transactions API less useful as a large portion of customers to their primary transactional banking from their credit card (mainly because of things like paywave and loyalty schemes). | Hi David Mitchell (Unlicensed) We raised this as a business decision /wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/22282274 - and the Business Working Group made a decision (Option 1) for v2.0 to continue with the approach taken from v1.0:
As this was the business decision - we have reflected this in the technical specifications. This will be fed back to the business group for the scope for pipeline activities. |
Payments NZ | Errata | Errata:
| |
Xero | DevelopmentPipeline | Payments API - future standards:
Account Information API
Bills API
| Hi Chris Barton, Thank you for providing your thoughts and feedback on what you consider to be the high priority areas for future state standards development. We will be incorporating all feedback received on the pipeline, through the Business and Technical working group(s) and relevant governance processes following the consultation period. |
Dimitri Stylianidis (Deactivated) Xero | Development Pipeline | Feedback on Account Information API Specification v2.0.0
| Thanks for your feedback on the Account Information API specification Dimitri Stylianidis (Deactivated). We will be incorporating all feedback received on future state of the APIs, through the Business and Technical working group(s) and relevant governance processes following the consultation period. |
ACC | Multiple | As a potential third-party user of the API standards, I see the benefits that the Payments Initiation and Account Information Standards provide to an organisation such as ACC, however given the following factors, these would complicate their implementation for third-party users:
| Response to be confirmed. |
ASB | Multiple | Release candidate 001 - v2.0.0-rc1 The “Consultation and feedback section” link is not working. NZ Banking Data API Specification v2.0-rc1 NZ Banking Data API Specification v2.0-rc1 “This document and its sub-pages must be read in conjunction with the Known Issues Log” – It would be helpful if a link to the ‘Known Issues Log’ was included (as was done in upstream version). It would also be useful to have an overview table of all APIs and endpoints on this page with a short description for each API and whether they are mandatory or not. This will give Third Parties and API Providers a good overview of the endpoints that are covered by the specification. Similar to the tables at the top level of each specification (e.g. https://paymentsnz.atlassian.net/wiki/spaces/ACSC/pages/49283859/Payments+Initiation+API+Specification+-+v2.0-rc1) Account Access Consents v2.0.0-rc1 Account Access Consents v2.0.0-rc1 The plurality of account access consents should be consistent throughout the documentation: account-access-consents vs account-access-consent (account-access-consents is correct). This NZ spec appears consistent with the upstream spec so we are unsure if this difference is intentional. “An API Provider may delete the account-access-consent resource 24 hours after creation if not authorised by the Customer or, if authorised by the Customer, 24 hours after the specified expiry date.” This is a bit ambiguous / unclear and may be clearer in the same form as the specification page
However, this does highlight the inconsistency between the two pages. The first states “if [the consent was] authorised by the Customer, [the consent may be deleted by the API Provider] 24 hours after the specified expiry date”. The second bullet point above states: “the API Providers may archive an expired ConsentId after 24 hours of creation”. Note the discrepancy between 24 hours after expiry vs creation. Also, the Domestic Payments Consents page https://paymentsnz.atlassian.net/wiki/spaces/ACSC/pages/49284091/Domestic+Payment+Consents+-+v2.0-rc1) does not mention archiving or deletion. It seems that these should all be consistent and use a consistent term (archive or delete). Upstream has different wording, but essentially they specified that consents can only be deleted 24 hours after creation:
Accounts v2.0.0-rc1 “The first step for a Third Party after an account-access-consent is authorised – is to call the GET /accounts endpoint” It is not immediately clear why this endpoint needs to be the first step after account-access-consentId. Also, the Third Party’s first step might be to do something else, e.g. retrieve the consent first. For clarity, it may be better to state explicitly: “For the Third Party to retrieve resources that require an AccountId, e.g. GET /accounts/{AccountId}, the Third Party will need to call the Get /accounts endpoint first to retrieve the AccoundIds”. The NZ spec is consistent with upstream here, but we feel could be clarified. Beneficiaries v2.0.0-rc1 It appears that the Creditor agent is mandatory in the UML diagram (1..1), but optional in Data Dictionary (0..1). This appears to be a deviation from upstream where it is consistent in both. Direct Debits v2.0.0-rc1 The examples have GBP. To be consistent with other examples, it should be NZD. Transactions v2.0.0-rc1 Filtering – it would also be useful to filter by minimum and maximum amount. Suggest this for consideration for future versions. | Response to be confirmed. |
Vigilence | Development Pipeline | Vigilance is looking forward to using the PaymentsNZ API when it is able to process bulk batch payments from a bank account that is a Business account and likely to require multiple authorisers. Vigilance already allows for batches to be authorised by multiple people, so would like to allow this pre-authorised batch to be processed via a future API. The ability for payments to be made to Foreign bank accounts is important. Before each single payment in a batch is processed, we would like to use an API to check that payee's bank account to verify the account name and compare with the name the payer has on file - any difference to be warned about before the payment happens - so there is a chance to cancel. Comparing names has a challenge with slight spelling differences, so some 'nearly matching' would be great. Being able to download bank statement transactions is likely to be the first API we could use - the most valuable information on each transaction would be the 'other party' details - name, account #. Plus if the transaction is deposit from a foreign account, we require the swift details, bank, branch - all for AML/CFT purposes - to enable us to create a Prescribed Transaction Report to the FIU. The Party API would also be very useful for AML/CFT purposes for helping to build a complete picture of a transaction.We look forward to a possible timeline of when some of the above functionality may have research started and happy to provide more specific suggestions then.The API documentation seen to date has been clear and well written. | Response to be confirmed. |
Dermot Butterfield (Unlicensed) WYCH Limited | Development Pipeline | Deviation from OBIE Enumeration standard. There appears to be a change from the technical specifications as outlined in https://openbanking.atlassian.net/wiki/spaces/DZ/pages/937623722/Namespaced+Enumerations+-+v3.1 and omits any clarification or supporting documentation on the need for a deviation from the industry standard. Further in deviating form the standard it omits to declare the behaviour of the banks with regard to bank specific additions which we clarified in the standard. The introduction of namespacing was an improvement to avoid collision on standard and non-standard (ASPSP specific) types. The specification defines a prefix of country in ISO 3166-1 Alpha-2 code followed by full-stop, followed by camel cased ASPSP name followed by enumeration value. I appreciate the desire to NZ-ise this but this can be achieved while aligning with the standard. I would expect for example a root specification prefix of one of the following. Considering PaymentsNZ as the specification owner NZ.PaymentsNZ.AwaitingAuthorisation
Considering PaymentsNZ apicenter product as the OBIE equivalent NZ.ApiCenter.AwaitingAuthorisation
Considering this an open banking spec NZ.OBIE.AwaitingAuthorisation
it is questionable if the standard is an open banking standard The proposed apicentre.paymentsnz.co.nz.AwaitingAuthorisation total prefix size 26 characters in the example (and many others) the proposed prefix is longer than some of the previous example with the Enumeration attached does not align with the country standard prefix uses a domain name format references a product name unclear how this supports bank additions such as must end in co.nz? must be lowercase? e.g. westpac.co.nz, KiwiBank.co.nz, ASB.co.nz e.g. api.westpac.co.nz, api.kiwibank, nz.asb | Response to be confirmed |
OrbitRemit | Development Pipeline | Feedback on the Account Information API: I would like to echo comments on mandatory immutable transaction_ids (even if the bank line information has been updated) and account_name fields. Further/additional justification for these changes: Providing transaction_ids would allow for real-time reconciliation. Populating the account_name field is crucial, particularly with tightening AML/CFT regulations. | Response to be confirmed. |
Trustees Executors Limited | Multiple | Links in version control don't work when referencing draft1
Accounts v2.0.0-rc1
Inconsistent security model applied. you want feedback, but we can't view all the documentation. Example link /wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/22282274 gives 'This is a restricted space' error (which is provided in feedback, and referenced in the V2 spec) Scheduled Payments. Error in version control, version 1.0.0 states "baseline specification for party resource" (rather than scheduled payments) Mandatory immutable transaction ids, these are currently optional. would assist to ensure unique information supplied. As a 3rd party looking to utilise for commercial purposes. We need to ensure what data is actually going to be provided. Would it be plausible for a technical template that each provider could complete to advise what fields each is going to make available (by account type?).
Without, this exercise would be done by each 3rd party. Providing it could speed up any developments. Payments Initiation. Term Deposits is a common banking instrument and should be an endpoint. GetRates CreateDeposit UpdateDeposit TerminateDeposit | Response to be confirmed |
Add Comment