Finding 1: NPP\u2019s PayTo will be the first brand of \u2018Open Banking Payments’, however it is a closed ecosystem with mandates only accessible by those connected to the NPP<\/h2>\n\n\n\n
Description<\/strong> A use case of this is an application where a consumer can see all their upcoming payment obligations in one spot, as well as assisting Banks with keeping track of where their PayTo obligations are held (currently, these sit at the merchant level, not the bank level).<\/p>\n\n\n\n Suggestion<\/strong> The alternative to solve this is a federated digital identity framework however this is a significant piece of work and CDR is a more viable solution given its design as an Open Banking ecosystem.<\/p>\n\n\n\n Description<\/strong> Suggestion<\/strong> Open app -> connect bank account -> consent to data sharing -> select auto-top up -> select PayTo -> consent to third party payment initiation -> complete<\/p>\n\n\n\n This adds an additional few steps to the user experience including confusion over a separation of the data that is shared, how long for, and how it is managed. Friction is brought into the user experience, where ideally the consent to capture data under CDR would include the consent to capture an NPP mandate, such that the flow would be as follows:<\/p>\n\n\n\n Open app -> connect bank account -> consent to data sharing and payment initiation -> complete<\/p>\n\n\n\n The above flow will be possible via Action Initiation, however it is encouraged that these consent flows merge in the short term.<\/p>\n\n\n\n Description<\/strong> This separation of experiences may be confusing for a customer, given that PayTo is ultimately a \u2018Pay by Bank\u2019 method, but using different payment rails. This will significantly hamper the uptake of both third-party payment initiation for consumers. Consumers are not fussed whether it goes via direct debit rails or NPP.<\/p>\n\n\n\n Suggestion<\/strong> Third party payment initiation in Australia will bring to life a number of exciting innovations, provide a slick user experience and utilise Australia’s world-leading fast payments infrastructure. There are some minor gaps between what is being achieved by PayTo and what CDR action initiation seeks to achieve. Basiq believes that alleviating these gaps will make for a great consumer experience and benefit all stakeholders involved in the future of third party payment initiation in Australia.<\/p>\n\n\n\r\n
Mandates stored under NPP\u2019s PayTo are stored in a centralised database. Each mandate is attached to a bank account (usually the PayID attached to that Bank account). \u00a0Although a \u2018single access point\u2019 is desirable for those connected to the NPP, it reduces the open nature of data sharing that is distilled under the CDR.<\/p>\n\n\n\n
It would be beneficial to allow mandates to be transferable under CDR. This means that if a consumer has multiple PayIDs (which is commonplace given the multi-banked nature of Australian consumers) with multiple mandates, then there is no way the consumer can visualise them in one app view without logging in \/ creating a new session on a per-PayID (or Bank account) basis. If mandates were shareable via CDR then I could attach multiple bank accounts and visualise all mandates within a single view, including those that are not via the NPP such as BPay or Direct Debit. CDR authorisations are not stored centrally and designed as a contract between the Accredited Data Recipient (ADR), the consumer and the Data Holder (DH) via an access token \/ refresh token model.<\/p>\n\n\n\nFinding 2: There is a separation of consent flows between those outlined by CDR and those developed by the NPP.<\/h2>\n\n\n\n
The NPP has its own consent flow that has been developed outside of the rigorous consent capture dictated by CDR. The capturing of a mandate will require a separate UX flow and require disclosure of different attributes to those at the CDR level. The session noted there will be workshops to integrate the consent flow however this should be prioritised so as to not affect the user experience and friction involved in the short term.<\/p>\n\n\n\n
If there is a request to share data (say, logging into a microinvesting app and connecting your bank account) then there will be an additional step and consent flow to then authorise a recurring monthly top up of that account via PayTo. See flow below on consent for data-sharing and consent for a PayTo mandate:<\/p>\n\n\n\nFinding 3: PayTo alongside other Open Banking payments methods in the future (such as those via CDR’s action initiation) may confuse consumers<\/h2>\n\n\n\n
If a consumer were to prefer to use an Open Banking direct debit payment – typified in the UK by the \u2018Pay with Bank\u2019 option, then there would be a separate UX flow (and payment button) for \u2018Paying by Bank\u2019 alongside PayTo.<\/p>\n\n\n\n
If PayTo were governed under the CDR framework, a consumer could \u2018Pay by Bank\u2019 and have the choice as to whether that is via PayTo or via Direct Debit, or even a one off payment via credit card – and the consent to capture would be as part of one flow, as mentioned in Finding 2. When CDR payment initiation arrives, merchants will also have to consider integrating multiple third party payment initiation rails. <\/p>\n\n\n\n![\"\"](\"https:\/\/wpbox7.net\/d8\/22c42489\/wp-content\/uploads\/2021\/08\/ob-payments-for-netflix-1024x571.png\")
<\/figure>\n\n\n\nSummary<\/h2>\n\n\n\n