Introduction

Welcome back to another edition of the Basiq Insights series. This week, we debunk what is meant by ‘Open Banking Payments‘. At its highest level of abstraction, Open Banking payments represents the confluence of payments and data. Although valuable, this is far too broad a statement – so this piece will glean what Open Banking Payments means within the Australian regulatory landscape, the industry players and the benefits for merchants and consumers alike.

Open Banking and Payments

Open Banking can provide third parties with customer-consented access to financial data. Similarly, payments can often be executed by an individual via either a ‘push‘ payment, such as paying your friend for your share of dinner, or a ‘pull‘ payment, such as authorising Netflix to charge your card $14 per month. The main delineation here is that with a push payment, you are manually sending the money through an interface, while a pull payment is being executed on your behalf, by a trusted ‘someone else‘ – such as a direct debit (note this is illustrative – not always true). So, is there a way we can trust a third party with both our data and a payment instruction, and what does this look like?

Netflix

Let’s extend the Netflix example to see how it would look with both Open Banking + payments. Imagine signing up to Netflix for the first time, adding your personal details, then selecting a payment method and adding your card details. Instead of adding your card information, you could select ‘Pay by Bank‘ and then log-in with your banking credentials, select the account you want to pay from, and then the transaction is complete and you’re up and running. Then, every month, your account is direct debited and the money is pulled from your account – because you consented to it. Let’s unpack this in detail:

When you select your Bank, you then:

• Are redirected to your Banking app
• Receive a one-time-passcode (OTP)
• Enter the OTP into Banking app
• Return to Netflix, select your account, e.g. your Every Day Account
• Consent to Netflix performing a debit on that account (a ‘pull‘ payment) each month, for $14.

There’s two ways you can consent to this user experience – either via a Direct Debit (the most common way pull payments are performed) or via PayTo (which will be rolled out from mid-2022¹).

Scenario (a) – Direct Debit
Via the direct debit flow, what you’re doing is storing an agreement – or an authority – for a third party (Netflix) to withdraw money from your account (the Every Day account) every month for $14. This is known as an ‘Account to Account‘ or ‘A2A‘ payment, whereby the money is sent, by a third party, from your account to another – in exactly the same way you would transfer money from your Every Day account to Netflix’s BSB and Account Number (for example). One of the downsides is that via Direct Debit, a consumer can send the money, but it will (generally speaking) take ~2 days to arrive. This is because the underlying infrastructure, the Bulk Electronic Clearing System (or BECS), is an old school architecture that will withdraw but it will take 2 days to settle on the interbank network (complete with delays on things like public holidays, or weekends – hence the ‘business day’ disclaimer for many purchases). See the Open Banking DD flow below:

You’ll notice in the image above that ‘BECS‘ is the underlying infrastructure. BECS is a legacy system that settles ‘Direct Entry‘ payments (e.g. direct credits or direct debits) across Australia. To give you an idea of how important this system is, in May 2021 there was a value of $1165589.3 million sent through the DE system, with 276599.6 (‘000) payments². This can range from payroll, to large scale M&A settlements, to you transferring money to a friend.

Enter NPP and PayTo

Australia’s New Payments Platform (NPP) allows for the facilitation of real-time payments from a payer to a payee. It’s a well established piece of payments infrastructure and the volumes it supports are absolutely massive – $77175.1 million in May 2021 and 79324.8 (‘000) individual transactions². Not as large as Direct Entry, but these numbers are increasing month on month. Most importantly – the NPP is 24/7 – which means real-time transfer and settlement, complete with no delays on public holidays, for example.

If you’ve set up a PayID before, or used Osko, the NPP payment infrastructure has facilitated that payment. If you haven’t – give it a crack – it’s a lot easier to remember a PayID (e.g. an email address or phone number) than a BSB / Account Number!

Direct debits have a number of benefits – notably customer familiarity and existing integration with a number of checkouts / merchants. But there’s a new kid on the block, named PayTo, which does exactly what a Direct Debit does, but uses the NPP system, or rails, under the lid. Remember how I mentioned earlier that a direct debit is similar to you transferring money from your BSB/Acc Number. to Netflix’s BSB/Acc Number? This is pretty much the same model, but replace BSB/Acc Number with PayID.

Scenario (b) – PayTo
PayID is the unique identifier attached to an individual bank account, that facilitates real-time payments from a payer to a payee. There are exceptions to this rule, such as dynamic PayID generation, but they are out of the scope of this piece. Every time you authorise a Direct Debit to withdraw your money from your account, you create a Direct Debit Authority – or a trusted third party to initiate this payment on your behalf. And yes, this has been mentioned a number of times, but this is incredibly critical when discussing Open Banking Payments. Let’s take the example above – of connecting your account – with the next iteration of PayID – also know as ‘PayTo‘ or the ‘Mandated Payments Service’ (‘MPS‘) (told you payments love their acronyms) – you’re doing exactly what a direct debit authority does, but the payment is settled instantly – and you only require your PayID on checkout. See below:

Above you’ll see that the PayIDs are the unique identifiers, and that although the account -> account transfer is the same thing, we see a new term – the ‘mandate‘. A PayTo mandate is an object attached to the PayID that essentially says “I approve this third party to withdraw money from my account using NPP rails”. A PayTo mandate and Direct Debit authority are essentially the same thing. The difference between PayTo and Direct Debit? In a direct debit world, you’d be saying “I approve this third party to withdraw money from my account using Direct Debit rails”. Feels complicated for no reason, right? Well, welcome to payments. There’s actually so so much more to talk about with this implementation.

See below an Open Banking flow that uses MPS. Note that PayID is attached to a mandate, but this flow allows for the capture of consent and sharing of data in one place. There’s more later on why Open Banking + PayTo is more powerful than just capturing a mandate.

One off payments v.s. Recurring

The above illustration of the creation of the ‘mandate‘ – or the third party that can execute a payment on your behalf – can work for both one off and recurring payments, in the same way a direct debit can. Ultimately, with a direct debit, the settlement takes time (t+2) whereas over the NPP it’s instant. This is super powerful, especially when confirming that a payment has come through if you’re paying with QR code (but that’s for another time).

Benefits
So, where does Open Banking come in? Let’s start with scenario (a) – via direct debit rails.

(a) Open Banking DD
There are many benefits of using Open Banking for direct debit, including, but not limited to;

(i) Eliminate dishonours…
… via Balance check – check the account has sufficient funds before triggering a payment in order to ensure there are no direct debit dishonours (which costs the payfac / payment processor money and ensure the consumer doesn’t go into overdraft).

(ii) Failed payment management…
…via balance check – if the account doesn’t have sufficient funds, then either reach out to the customer to let them know that they do not have sufficient funds and enter into a hardship reporting process, or a proactive message to say it’s okay the money didn’t come in – or even a repayment plan. This is to improve the customer experience outside of a “hey your money didn’t come in so therefore we are charging you more” #heartless.

(iii) Event-driven payments…
…this allows for the establishment of rules or events, such as the deposit of salary, to either pay a bill, or even more swankily – automatically sweep money to an account (the reason I bring up the latter is because only just a few weeks ago the EU/UK’s CMA mandated that consumers should have the ability to automatically transfer their information – both payment and data – to a new provider, on behalf of a third party – with the few clicks of a button)

(b) Open Banking PayTo
We can use examples i, ii and iii to extend the use case to PayTo. Although the payment rails are different, there is an additional benefit, notable from a UX perspective:

(iv) Include the consent capture for a PayTo mandate …
…within the same UX flow as customer-consented data e.g. a user only has to consent for the sharing of their data as well as a third party to initiate the payment on their behalf.

The above example is increasingly noticed amongst the CDR and NPP alike as a necessary next step in the CDR-direction.

Regulation?

There’s been a multitude of regulatory bodies and players in the above analysis and the good news is – the regulation has adapted extremely well to the convergence of Open Banking and Payments. As demonstrated by the partnership between Basiq and a payments processor – this has been possible for years. In other words, allowing a data provider (Basiq) to initiate payments via a provider (e.g. Payments processor)  – has been possible through digital data capture (screen scraping) and the creation of a direct debit authority. However, with the advent of Open Banking and NPP/MPS (PayTo) – this is providing new technology to support both customers and merchants alike by enabling greater payment optionality, both rails and the payment provider.

The MPS is managed and governed by the NPPA (the New Payments Platform Australia) – Industry Level, whereas Open Banking comes under the blanket of the Consumer Data Right – at a Treasury (Federal) level.

With the advent of ‘Action Initiation‘ – which is an extension of Treasury’s CDR, we can hope for the merge of  both Governing Policy and User Experience (which the CDR has set incredibly-well laid out guidelines for). This would mean that at the same time of capturing consent to share data, the consent to a ‘pull’ (mandate or direct debit) can be consented to in tandem.

Action Initiation

The next iteration of the CDR is to do with ‘Action Initiation‘, or write access. Currently, Open Banking is read access only (a bit like a push payment if you think about it), and now the framework is extending to an incredibly powerful next step of allowing third parties to trigger payments on your behalf. Yes, MPS can do this already – but there’s so much more than payment initiation.

The orange arrow below indicates where the confluence of NPP’s MPS and Treasury’s CDR hopefully arrives at:

Fig 2.0 – Action Initiation Regulatory Convergence

The above illustrates that CDR has been concerned with Open Banking; and NPP with Payments. The orange line shows that hopefully Open Banking, under CDR can have the ability to execute payments via the NPP rails as opposed to just DD (e.g. current state with Basiq and a payments provider). PayTo is highly similar to an Open Banking direct debit authority via customer-consented access to financial data – so this convergence can bring to life countless innovations to serve the financial services payments and data landscape.

Action Initiation has a raft of other action types it can instruct, the innovation possibilities are huge so we will leave that for another instalment.

References

1. NPPA – PayTo: https://nppa.com.au/payto/
2. RBA Payments Statistics: https://www.rba.gov.au/payments-and-infrastructure/resources/payments-data.html