...
Contributor | Category | Feedback | Response | |||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 1 | 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. | ||||||
| 2 | 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. | ||||||
| 3 | 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 | ||||||
| 4 | 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 | ||||||
| 5 | 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 | ||||||
| 6 | 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. | ||||||
| 7 | 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. | ||||||
| 8 | 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: | |||||||
| 9 | 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. | ||||||
| 10 | 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. | ||||||
| 11 | 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. | ||||||
| 12 | 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. | ||||||
| 13 | ASB | Multiple | Release candidate 001 - v2.0.0-rc1 The “Consultation and feedback section” link is not working. | |||||||
| 14 | 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 | ||||||
| 15 | 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. | ||||||
| 16 | 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. | ||||||
| 17 | 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. | ||||||
| 18 | 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. | ||||||
| 19 | 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 | ||||||
| 20 | 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 | ||||||
| 21 | 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 | ||||||
| 22 | 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. | ||||||
| 23 | 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. | ||||||
| 24 | 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. | ||||||
| 25 | 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. | ||||||
| 26 | 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. | ||||||
| 27 | 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. | ||||||
| 28 | 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. | ||||||
| 29 | Trustees Executors Limited | Multiple | Links in version control don't work when referencing draft1
Accounts v2.0.0-rc1
| Thank you for your highlighting this error, this will be updated and corrected in v2.0-rc2 | ||||||
| 30 | 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)Andrew Beech | Apologies for the inconsistency here. We will ensure this link is removed following publication of standard. The Business Decision highlighted is held within the standards development area of our Confluence space, only accessible to registered Standard Users of the API Centre. | ||||||
| 31 | 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. | ||||||
| 32 | 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. | ||||||
| 33 | 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:
| ||||||
| 34 | 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. | ||||||
| 35 | 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. | ||||||
| 36 | 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 | 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. | ||||||
| 37 | 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)The principle we have kept in the design of the APIs is explicitness. The ability for a Customer and Third Party to agree a defined enduring payment consent with fixed limits promotes more explicitness in the APIs. 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. | ||||||
| 38 | 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-PSP%263rdpartyAppsipo 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. | 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. | |||||||
| 39 | 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 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. | ||||||
| 40 | Multiple | Other Use Cases with Potential
| 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. | |||||||
| 41 | 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 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. However - to address a few of the specific points:
Can you please elaborate on (1) account statement narrations and (2) liquidity and settlement related aspects? | |||||
| 42 | Westpac | Multiple |
| |||||||
| 43 | Merco |
| Feedback in this document has been separated and responded to below. | |||||||
| 44 | Enduring Consent | Enduring Consent –Threshold Workaround We were advised the Technical Group had taken the decision to remove the previously agreed Threshold from the V2.0Standard for “technical reasons” noneof which have been defined... We note the Threshold has subsequently found its way onto the list of potential future Payment API upgrades? It is our view the Threshold will be a significant element in the success of Enduring ConsentPayments and in itsabsence,there is little to differentiate the payment processes associated with the existing Direct Debit system from the payment process in the proposed Enduring Consent process. Consequently, without Threshold functionality there is little new to offer our potential customers. The process around the Enduring Consent(authority) is another matter and obviously there are significant process improvements in what is proposed. Merco is faced now in making theproposed workaround a viable product using the decoupled flow. In short this means potentially: It is our view this is a significant departure from any existing banking practice in that the Customer could be of the view they were Consenting to a “bank authority” whereas potentially the bank could process many payments which can’t possibly be associatedwith the authority. This is totally at odds with the defining features of anyOBIE API solutions.It is our view that such a process is a new concept in payments where a Third Party initiates payments in terms of an authority the Bank is potentially NOT a party to (in terms of thepayment instruction) and the Bank thus becomestotally reliant upon the Third Partyacting in accord with the Consent.In a technical sense Merco believes it can build a workable product using the workaround. Merco however hasreservations whether the workaround is consistentwith the API Centres terms and conditions or whether a bank would pay away in such a scenario.We have been seeking PNZ assurances that the workaround is consistent with the API Centre’s terms and conditions as well as common banking practice since early November2019. We have not received any such assurances to date.Without thoseassurances Merco does not consider the workaround a viable solution. | Within the standards there is already capability to link (1) a one-off payment for a Customer (that is over an enduring payment consent threshold) using a decoupled authorisation request, to (2) a previously authorised enduring payment consent. All these specific circumstances must be in play together - e.g., if an API Provider does not support the decoupled flow - then the Third Party cannot initiate a decoupled flow linking the authorised enduring payment consent. Equally, if there is not previously authorised enduring payment consent. As this is specific behaviour and not generic behaviour - the clear design preferences is not to make generic API changes (like Status changes for the entire payment flow, or a new flag for the entire payment flow) to satisfy this requirement. Linking a (1) one off decoupled domestic payment to (2) a previous enduring payment consent is achieved by:
Further - the principle we have kept in the design of the APIs is explicitness. The ability for a Customer and Third Party to agree a defined enduring payment consent with fixed limits promotes more explicitness in the APIs. Previous discussions on using the decoupled flow for threshold flows are here: /wiki/spaces/PaymentsDirectionAPIStandardsDevelopment/pages/2196805 | |||||||
| 45 | Merco | Naming Conventions | Naming Conventions DebtorAccount In the Swagger Specifications the name DebtorAccout is defined as:Unambiguous identification of the account of the debtor to which a debit entry will be made asa result of the transaction. In many use cases payments will originate from accounts other than that of the Debtor (as defined in Commercial Law in New Zealand). The use of the term DebtorAccount to define the bank account from which payments will be made is misleading. The debtor and payer could be separate individualsand the name of the debtor known by the Payee in a commercial sense and the name of the underlying bank account from which payments will originate could certainly be different. The use of the term PayerAccount to define the bank account name from which payments will be made would provide unambiguous identification of the bank accountname as opposed to the debtor’s name.. | Principles we have carried over from v1.0 to v2.0 of the NZ API Standard are:
The use of the field DebtorAccount is consistent with both (1) ISO 20022 and (2) Open Banking UK. So the definitions are well known. The alignment to ISO 20022 and Open Banking UK may be re-assessed for future versions of the standard. | ||||||
| 46 | Merco | BACHO | Handling of the Payer Data in the BECS BACHO Payee (Creditor) RecordTo provide consistency with existing payments practice and to ensure meaningful data is provided on Payee’s bank statements in the “Other Party” field,API providers need populate the outward BACHO credit payment record correctly. Either the DebtorName can be used if present in the API Calls orthe Payer Bank account name can be used if theDebtorName is not present. If the Third Party has supplied the DebtorName it must be used in preference to the Payer Bank account name. The field we refer to in the BACHO record is that referred to as the “OtherPartyName” field, position 108. | As noted - this is a matter relating outside of the Standard - however, we can seek clarification with API Providers. 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. | ||||||
| 47 | Merco | Authentication | Authenticationand AuthorisationTimeoutsWe wish to discuss the timeoutwithin which the customer mustrespond to the authentication and authorisation request from the API Provider. In talking with the BNZ this timeoutis set at 5 minutes. We believe this timing is adequate based onMerco’s experience where we set this time out to 30 minutes. In our experience 8% of initiated transactions timeout for the non-completion of this stepwhere the payer has initiated the transactions. For enduring consent payments, the incidence of timeouts would be much higher where the Decoupled workaround is used to effect authorisation (i.e. Threshold processing). It is therefore significant and needs to be properly considered. If all API providers have differing timeouts for this process the Third Party will have difficulty managing the resubmission of the Consentacross many API Providers. We’d like an industry agreed timeout periodfor all API Providers for this step. | 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. | ||||||
| 48 | ANZ | The following interim feedback was received by ANZ. Note that the API centre has granted an extension to ANZ to enable them to provide additional feedback in early January. ANZ believe that supporting content is required to help participants of the standards understand how to navigate and use them. More specifically, we suggest that there would be high value in a separate onboarding playbook for API Providers and Third Parties, that would allow someone new to the standards to quickly develop their mental model of the domain. This could be achieved through example reference architecture, wayfinding support through the standards, consent and security constructs, and clear and specific interaction requirements: all leading to a broad understanding of the implementation requirements for participants. | A response is due in January 2020 upon the submission of ANZ’s final feedback. |
