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 | In both the Account Information and Payments Basics/Steps section - clarify “Once the consent has been authorised, the API Provider may make a callback to the Third Party to provide an access token.” - as the push method has been de-scoped by the FAPI working group. | To be updated in v2.0-rc2 |
Payments NZ | Errata | In the Payments Initiation Basic/Steps section - update “The Customer selects the debtor account(s) at this stage (if not previously specified in Step 1)." to reflect only one debtor-account may be selected. Linking multiple debtor accounts to an enduring payment consent has been de-scoped from v2.0. | To be updated in v2.0-rc2 |
Payments NZ | Errata | In the Payments Initiation Basic/Steps section - update wording for clarity from “may only create multiple” to “may create multiple” | To be updated in v2.0-rc2 |
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: | |
ACC | Multiple | The fact that bilateral agreements need to be put in place with each individual API Provider (currently there are 9 listed on the website), rather than a single organisation that facilitates connectivity between the third party and the banks. | Noted. 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. |
ACC | Multiple | The fact that some elements of the individual APIs are optional, meaning that each API Provider could provide a slightly different level of service to the others. Third-parties will have to cater for this themselves on an API, by API Provider basis. It is noted that the mandatory endpoints are probably the ones that ACC would use. Although I can see a use case where Party information (currently optional) within the Account information specification would be desirable. | Noted. 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. |
ACC | Multiple | I saw enduring consent as being a game-changer for the use cases by which these APIs could be used, however with this being implemented as an optional offering for the API Providers, this could lead to a less favourable user experience for end users whose API Provider banks do not support this capability. This could lead to an increase in customer contacts for the third-party where enduring consent is not offered by the appropriate API Provider. | Noted. 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. |
ACC | Multiple | As for future use cases that these APIs could possibly support, one that I have heard discussed, but I accept may not be desirable for security reasons, is where a payment could be initiated as a result of an invoice payment request being received by email for example, rather than from within a user authenticated channel/portal such as MyACC for Business. | Noted. 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. |
ASB | Multiple | Release candidate 001 - v2.0.0-rc1 The “Consultation and feedback section” link is not working. | |
ASB | 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). | As we’re still in development for v2.0 we do not have a Known Issues Log as yet. We will update this when we release v2.0 |
ASB | NZ Banking Data API Specification v2.0-rc1 | 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) | The endpoints and whether they are mandatory/optional are described in each API Group page: Would prefer not to duplicate these across the specification - as the main spec page is for only elements that are common for both API Groups. |
ASB | 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.” | We can update this in v2.0 to reference resources in plurality. |
ASB | NZ Banking Data API Specification v2.0-rc1 | 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. | We can look to clarify this in v2.0-rc2. |
ASB | Domestic Payments Consents | 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:
| We can look to clarify this in v2.0-rc2. |
ASB | 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. | We can clarify this in v2.0-rc2 |
ASB | 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. | The data dictionary is correct in this instance.. To be updated in v2.0-rc2 |
ASB | Direct Debits v2.0.0-rc1 | The examples have GBP. To be consistent with other examples, it should be NZD. | To be updated in v2.0-rc2 |
ASB | 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. | Noted. 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. |
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. | Noted. 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. |
Vigilence | Development Pipeline | 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. | Noted. 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. |
Vigilence | Development Pipeline | 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. | Noted. 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. |
Vigilence | Development Pipeline | 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. | Noted. 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. |
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 | There is no guidance on Namespaced Enumerations in the standard because there are no Namespaced Enumerations in the standard. I.e., all enumerations in the standard are of a fixed enumeration - as per guidance in https://paymentsnz.atlassian.net/wiki/spaces/ACSC/pages/49283453/NZ+Banking+Data+API+Specification+v2.0-rc1#Enumerations.1 EnumerationsThe specifications include various enumerated data types, where values are fixed to a defined set of alternatives (i.e. static enumerations). These static enumerations are listed on each API Specification page. This decision was taken to standardise enumerations across the industry in NZ - rather than to allow API Providers to deviate from the standard. /wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/22577217 So in the examples given - all API Providers will be responding with a status of “AwaitingAuthorisation” instead of a namespace.AwaitingAuthorisation. Think this should simplify a Third Party’s implementation. |
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. | Noted. 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. |
Trustees Executors Limited | Multiple | Links in version control don't work when referencing draft1
Accounts v2.0.0-rc1
| |
Trustees Executors Limited | Multiple | 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) | |
Trustees Executors Limited | Multiple | Scheduled Payments. Error in version control, version 1.0.0 states "baseline specification for party resource" (rather than scheduled payments) | Thanks - we will update the version control section in v2.0-rc2. |
Trustees Executors Limited | Multiple | Mandatory immutable transaction ids, these are currently optional. would assist to ensure unique information supplied. | Noted. 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. |
Trustees Executors Limited | Multiple | 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?). This could then be presented on a page within the wiki (not sure if that is correct location) so when we are developing we can limit scope to data available from all, or know that we need to handle a lot of optional combinations (which would be a maintenance nightmare if changes were made). Without, this exercise would be done by each 3rd party. Providing it could speed up any developments. | A business decision was made on developer portal requirements /wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/22413350 - which had agreement for:
|
Trustees Executors Limited | Multiple | Payments Initiation. | The initiation of scheduled payments (which are initiated by the Third Party for a future date) are not in scope for the v2.0 standard: /wiki/spaces/ACSC/pages/49283242 . However - the ability for a Third Party to initiate a payment on a future date is possible with the enduring-payment-consents functionality in v2.0:
This has benefits over a regular scheduled payment - as a Third Party may not know the exact amount of the future payment - but can agree a maximum amount with the Customer. |
Trustees Executors Limited | Multiple | Term Deposits is a common banking instrument and should be an endpoint. GetRates CreateDeposit UpdateDeposit
Return the cost/fee to break the term deposit TerminateDeposit | Noted. 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. |
Multiple | Information around the transaction, Reconciliation, Reporting, Queries, Dispute ManagementEnd to End ID has to be a mandatory field by the banks(each party involved in the transaction remitter, remitters bank, beneficiary’s bank, beneficiary and the open banking app participants need to also store their “own reference numbers”)From a client perspective (the client supplied reference number) should also flow through all pay, collect, receive cases. This field E2E ID will flow through the message across all parties and will be used for reconciliation, disputes/charge back and inquiry / investigationsIn addition, for companies using this mechanism, the client reference number (invoice / erp number) should also flow through the transaction from remitter to beneficiary / origin to destination. | ||
Multiple | Reference to Enduring Consent (Mandates for future execution) Sample physical mandate referenced from the real world Reference: National Payments Corporation of India Enduring payment consent is not handling amount variances and as and when presented scenarios. Real world issues have come up on the mandate where the Debit As and when presented feature has been used by Supply Chain participants in their use cases, similar use by Non Bank Finance Companies for loan security (invoke on default scenarios) Today, companies using the debit mandates (enduring consent) are faced with the challenge of a fix / max cap amount when the government decides to change GST rates and / or add service charge / cess components to the service tax structure. In all such cases the companies go out and re-seek mandates which is a tedious activity and cause for strong feedback to the clearing house and member banks. Enduring Consent for payments should also have the option of submitting payments "as and when" presented for submission.  | ||
Multiple | Use case references for Enduring Payment Consent UPI is not a case of pure open banking but it involves the creation of standard API’s by the clearing house which are consumed by participating banks. The PSP’s hook up to the bank switch through their own API’s. But the intent of pay, receive and collect remains the same. Here is a reference : https://www.npci.org.in/product-overview/upi-product-overview Case of Enduring Consent (UPI e-mandate) for Investors to use the ASBA (Application Supported by Blocked Amount) route for investing into IPO’s (Initial Public Offering)This is live in the real worldhttps://www.npci.org.in/upi-live-ipo List of 3rd party Apps - on boarded on to the UPI ecosystem(can demonstrate in person)https://www.npci.org.in/upi-PSP%263rdpartyApps Use cases which can be leveraged by the open banking ecosystemhttps://www.sc.com/upi/ Volumes and throughput flows rise when merchants get on-boarded to the ecosystem. Above link has use cases which can be referenced to get merchants interested. | ||
Multiple | UPI Primer https://www.youtube.com/watch?v=aUHiyQfb8s0 UPI Procedural Guidelines (Public Reference) UPI Procedural Guidelines (Nov 2019 Update) Reference attached UPI Procedural Guidelines - Pg 58: Four Party Model (Complex Flow)  Link to view full image - Four Party Model Figure 1  Link to view full image - Four Party Model Figure 2 UPI (Unified Payment Interface) crossed 1 Bn Transactions in Oct 2019 (142 participating banks and ~50 App first merchants) | ||
Multiple | Other Use Cases with Potential
| ||
Multiple | Other Aspects to Consider at an Ecosystem Level (so that participants play by the rules)
| ||
Westpac | Multiple | Thank you and noted. The API Centre is working through your feedback. We are pushing to provide you with a full response, and arrange an update on the overall v2.0 feedback. |
0 Comments