Dave Pike has over eleven years of experience with Commonwealth Bank, leading payments development and strategy. Specializing in real time payments, online business banking, and payments innovation, Dave is now the Head of APIs and Flows at eftpos Payments Australia. In this episode of If I Ran the Bank, Clayton sits down with Dave to discuss how banks can solve real customer business banking problems (like payroll) through embedded banking.
Don’t miss this episode with Dave Pike, listen below.
When I met you Clayton, I was working for a large bank, building payment channels and corporate internet banking channels, and exploring APIs with that bank. Right now, I’m working at eftpos, which is the equivalent of the Australian local debit card network. It's very similar to Interac in North America, where it has its own proprietary debit card, as well as being able to process Visa, MasterCard, and debit card transactions. My role there is head of APIs and new flows; trying to build capability for the banks to do more merchant acquiring sort of innovation.
If you ran the bank, what would you go all-in on?
My pitch would be to really get to know my business customers and look at their processes around accounts payable, accounts receivable, payroll, collecting money from consumers, disbursements to consumers, and seeing where the pain points are in those processes and then designing my products to be effectively embedded into those processes and solutions.
These ERP and accounting systems that are really rich in functionality and controls, separation of duties, aren't actually integrated with the customers’ base accounts. I would look at how I would get my bank products working with those systems.
For example, let’s look at payroll.
Companies typically use an outsourced payroll provider or may use their accounting system to do payroll. They'll have a payments clerk and then also have a CFO who actually approves payroll. But, they also have another person who actually takes the file out of one system and uploads it into the bank. There are all these controls that the customer needs to put in place to actually make sure that someone doesn't manipulate the file and pays the right person the right amount on the right day. And it's strange that the banks go, "Yeah, we're all about security and making you safe," but they actually make the customer do all the things that aren't safe. There are files being manipulated to actually input new account numbers or different amounts involved. But payroll — the banks basically forced the customer to do this, because they're not willing to integrate with these payroll providers. And they really only make this service available to the high-end, through file transfer.
So, I'd be pitching my business bank to my customer saying, "Hey, I'd love to integrate my bank and payment solutions into the systems that you use so that you can do fast, accurate payments, and make it really secure. And then you don't need to worry about having four people do your payroll." There are lots of examples where there are opportunities within business banking to sell the same service but distributed differently. It’s a win for the customer and a win for the bank.
These are the sorts of ideas that I would be pushing my product people to look at. How do we solve real customer business banking problems, as opposed to how do we sell more products?
So, in terms of pain points or jobs to be done for the clients — like payroll and accounts payable — could you expand on what you think the totality of those are? To actually execute that proposition strikes me as a lot of investment.
I'd be looking at what my customer base is and looking at what software they're planning to use or are using, and would target the top five. I'd target large corporate and government clients and then the bank’s top 200 business clients. They're probably the ones that are most valuable to the bank and most likely to appreciate the streamlined controls.
How are they integrated? That's actually a really hard question because there are three strategies:
All three models would work. It’s a question of finding the correct commercially-viable model for your bank. Because at some point, you're going to have to do some revenue share or share the cost somehow of that integration.
It's not like, "Build this integration well.” You've got to actually build at once and then maintain them with the particular software that you integrate it with. So, that I think is probably the more challenging question. And if I had the answer, I'd be running the bank.
Do you think in your world with your bank that the business model changes somehow?
Most customers in business banking don't pay much attention to transaction fees, they see them as a utility. So, as you do this integration, you're going to have to find ways to add value to the process that people actually are willing to pay for. Things like risk-based transactions scoring. If you're paying a new supplier and your account number bank hasn't seen it before, it would inform the person paying, "Hey, actually, this could be a high-risk transaction. Do you want to double-check the details?." They might pay for that sort of service as opposed to just processing my file or payroll. The other things banks could probably do is account verification, load balance notifications, notifications of incoming payments.
It's all about the added value, and the things that other banks aren't doing that people will find useful, provided they bring value to the business. So, if you're able to streamline a process or remove a number of steps, that means there are fewer operational people doing non-value-added services in accounts payable, accounts receivables teams, then you can charge more. If you, as a bank, provide services that remove the need for half that staff, then you're providing added value. But it's not just to provide the basic plan of service and accounts receivable, you've got to add value to those things.