Usage-Based Billing in Financial Services

Behdad: 
Hello and welcome to the Data for Subscriptions podcast, where we learn and explore how to run better subscription businesses. I’m your host, Berat Banyan, and I have the immense pleasure of welcoming Priya Ranjitha to the show. Welcome, Priya.  

Priya: 
Thank you so much for having me here.  

Behdad: 
Priya, you have an impressive background coming from PayPal, Stripe, Mango Pay, and now at WorldPay, where you’ve basically focused on pricing and monetization strategies. Before we get to the meat of the discussion today, we’re going to speak about specifically pricing models and usage-based pricing when it comes to payment processing firms. Tell us about what made you so passionate about this space and having spent the time you’ve done in the different companies and now and what took you to Worldpay.  

Priya: 
yeah yeah absolutely I’m happy to uh go over it so uh I mean I I don’t know for for some reason I’ve always been fascinated with uh financial services space in fact even when I was in consulting uh after a time I was focused on this vertical. So the interest has been there for a long time. And as I got to know more about the industry, it only became more and more interesting. It touches our lives every day, right? Every time you buy coffee, make any transaction. So it’s there everywhere around us. And yeah, I’ve been focused on, lately I think I’ve focused on monetization strategy, go to market and product strategy. And all these three areas, I think, are critical success factors for any company, I would say, generally speaking, but also especially in payments, pricing particularly. Just given how complex the usage metrics can be and then thinking through the right pricing model, given all of that, can have a huge impact.  

Behdad: 
You recently joined WorldPay. We’re going to come back to that as well, but payment sector. How would you describe the maturity when it comes to providing sophisticated or advanced pricing models where you also alluded to usage-based pricing?  

Priya: 
Right. So I think payments industry, when it comes to pricing models, it’s pretty mature. And if you think about the pricing structures, the pricing structures that we have, the pricing models that are being used by payments processors, they’ve been around for a long time. Now we’re seeing some evolution in certain ways. But yeah, in terms of maturity, they’ve been around for a long time. They’re pretty well established. And that’s what customers have come to expect now from their payments processors. So yeah, I would say highly mature and very, very usage based pricing models. Yeah.  

Behdad: 
So in this sector, the fact, the standard is usage based as opposed to some of the industries where they might have not even started with basic subscriptions. But for many other industries, you have that at least in place. What are the observations and trends that you see in this industry? Is it basically standardized and no movement at all? Or are we seeing shifts or different kind of models being tested or might even come changes?  

Priya: 

Yeah so uh so I would say I would think of it in two ways. So there is a vast majority of use cases for which pricing model is pretty standardized. And it hasn’t changed much. I mean, certain things change in terms of price points themselves, but in terms of pricing model itself, nothing much has changed or I think would change in near future. But then there’s this other set of, I would say use cases or customer segments or some specific customers from certain verticals that have slightly different needs than the majority of customers. And given that, their value metrics don’t align very well, probably with the usage-based billing models that are typical in payments processing. So for those segments now, what I’m observing is there has been there has been a trend towards customizing pricing models. So moving maybe slightly away from usage-based billing in certain cases as well to something more like a subscription kind of pricing. And the reasons behind that evolution are multiple, but I would say some of the key reasons are one, A lot of these customers want predictability in their costs. They want to know what their monthly, quarterly, annual cost of payments processing is going to be. So they prefer a fixed fee kind of model. And then another reason is it translates into a lot of operational simplification for these customers as well, which is important for them. So yeah, those are some of the drivers of this trend, I would say.  

Behdad: 
It’s interesting because this industry that has been further ahead than others, basically spearheading the usage-based pricing model, in a way is bringing in less mature models or we can just call it more flexible offerings because you can offer multiple ways to price it. Maybe the learning here is that the end game here is that you have a highly flexible and agile setup so that regardless of your customers preferences, you’re able to meet them with that specific type of offering. Because the observation we’re making as well is that the same that you mentioned in the payments industry, we’re seeing in other industries where one single modality doesn’t necessarily work. So if we take the simplest of cases where we’ve all enjoyed subscription, flat fee subscription models for more than ten years for media and entertainment type services, we’ve seen in the last couple of years that there is something off with the price value equation. So therefore, while the flat fee subscription model is not necessarily off the table, you need to be able to provide alternatives mode as well.  

Priya: 
I think that is the key. That is the key. You hit the nail on the head with that. You need to be open to customizing, changing your pricing model according to the needs of your customers. But of course, again, I mean, these decisions need to be taken cautiously because sometimes companies end up over customizing. Like, you know, they end up in a situation where you’re customizing your pricing models for customers. every other customer and that has a ripple effect on a lot of things, not to mention you are left handling a lot of operational complexities which you’re better off not handling. So I would say excuse me these decisions need to be very well thought through and you need to think about what your long-term business strategy is, your customers and uh why are these customers important to you and given that how much customization is okay for you and what effect does it have on your business model.  

Behdad: 
And this is an excellent point to come back to because later on in our conversation, I want to pick your brain, of course, within again, coming back to a heavy user industry like the payment sector, the level of back end, the muscle you need to have to manage all of the transactions. But let’s just say here and now that when we speak about having a flexible and agile system to be able to cope with customer needs and demand, you need to have that front end to be in liaison and alignment with the back end. So one of the recent customers that we’ve supported had exactly this situation we’re speaking about because they wanted to have a customized offering for every one of their large corporate customers around the world. And it turned out to be thousands of them. So this naturally created an awful lot of administration in the backend that their backend system wasn’t ready for. That resulted in them needing to put in a lot of people that drove cost, but still with data impurity, lack of data quality, which meant that they still were suffering. So kind of a really great initiation point and reason ended up creating a lot of issues for for this one client. Luckily, there’s a good solution for it, but one needs to make sure that the back end is willing and able to go down that route.  

Priya: 
Yeah, no, absolutely. Completely agree with you there. Yeah, I have been in situations where, you know, we acquired a company and then one of the companies I was at, much smaller company, and it turned out their pricing model was customized for every other customer. And that was not scalable. They were a really small company, so they somehow managed to pull it off. And a lot of processes were being managed manually. And the problem was, I think one of the biggest problems was that the customers were also dissatisfied. So it’s a trap, this thinking that if you customize for every customer, you’re going to have delighted customers and that’s going to help you grow. It’s flawed thinking because at the end of the day, given the complexities that you are introducing in your system, you’re not going to be able to keep your customers happy. What will happen is things like you’re sending wrong invoices. You are making errors when it comes to line item level description of the invoice. And as a result of that, your customers are unhappy. You spend a lot of time and energy just correcting those things that shouldn’t have been there in the first place. And in the end, because of that, not only you fail to retain a lot of your customers, but also it’s just a lot of negative PR. It does not affect your growth positively. 

Behdad: 
Let’s talk a little bit about the volume, because I think that it’s good for our audiences to understand what we’re speaking about, because telecoms industry, of course, can boast with really, really large volumes of transactions. But I would say the payment sector is one that is really, really impressive. So take us through from PayPal all the way through to WorldPay. What are we talking about here?  

Priya:
So in terms of, I mean, I can talk about these companies in terms of their level of maturity.  

Behdad: 
Let’s just give a bit of an approximation of what is the level of transaction volume we’re speaking about when it comes to PayPal and how many currencies and countries. Just give a little bit of a flavor for how complex and large this is.  

Priya: 
Yeah, yeah, definitely. So, I mean, PayPal, for instance, just to put things in perspective, processes around one and a half trillion dollars of volume every year. And it’s only growing. This is data from last year. So we’ll see a higher number this year. And more than fifty currencies, more than one hundred countries. And the numbers are similar or bigger for other players, if you talk about card players, they process north of 13 trillion a year. And that translates into billions of transactions, not in a year, but every day even. And then Stripe, for instance, processes one and a half, about one trillion dollar. That’s what they did last year. They are in, again, more than a hundred countries. They support more than fifty, sixty currencies. Similar numbers for WorldPay, they process around two and a half trillion a year and are present in, again, more than hundred and fifty countries. They support more than hundred currencies, I think. So there’s a lot of complexity. All these differences introduce a lot of complexity in terms of the kind of usage data that you need to capture and manage, to be able to, again, bill correctly. Because as a company, at the end of the day, you want to ensure that you’re growing, too, in terms of your revenue, profits. And your revenue is directly correlated with pricing, your billing, invoicing capabilities. It’s really fundamental. But the thing is, just given the level of complexity, even a lot of mature companies sometimes, I feel like, are in need of better data capture and management systems that are flexible, that are dynamic, that can evolve as your business model, as your revenue model pricing strategy evolves with evolving needs of your customers.  

Behdad: 
And I’m going to really double click on that statement that you had. But before we go there, if we use WorldPay now and those pretty impressive numbers of two and a half trillion in transaction, we have some plus hundred countries and equivalent amount of currencies. Then we use that as a jump off point into my next question is, let’s talk about some of the on-the-ground complexities that this creates before we walk into the back-end question that you just raised with the data capture. I want everybody to understand that this is actually really, really difficult with all the local jurisdictions and all the different payment methods that you also provide. Just walk us through a little bit of how that complexity looks like for WorldPay.  

Priya:
Yeah. So I cannot talk specifically about any company, but generally speaking, what I can talk about is maybe what a good sort of quote to cash system looks like and at what points there can be challenges. So generally speaking, a good system needs to have a I’ll talk about a different components in place that are linked very well together. So just talking about the billing cycle, it all starts with, you know, the quote creation process. So to begin with, you need to have a process and system for quote creation in place that supports the kind of complexity in pricing models that you have, you know, and by country, by currency, instance, if you talk about just in payments, if you talk about account to account transfer as a payment method, this payment method doesn’t have a variable pricing typically, it only has a fixed fee per transaction. Versus if you talk about, let’s talk about the most common payment method cards, Cards have a fixed fee plus a variable fee. So what that means is in terms of data capture and management is for account to account transfer, you don’t necessarily need the payment volume for billing purposes. You just need the number of transactions. But for a card transaction, you would need both, volume plus number of transactions so uh again your data capture management system needs to be intelligent enough to capture these different the right metrics for different payment methods and this can this obviously varies by currency and by country so it needs to be able to make that segregation and feed it back to your billing engine. So again, going back to this. So it starts with your quote creation process. That system needs to handle your pricing complexity basically. And then your billing engine needs to be able to, again, ingest the pricing information from your quoting tool. And then of course, and also handle the pricing complexity again, in terms of actually making the calculations. And so one piece of the input that billing engine gets comes from your quoting tool. And then the other piece is your usage metrics that needs to come from your data capture management system. So these three key components, your quote creation tool, your billing engine, your data capture management systems, at a high level. Once you get into nuances, you can break them down into much smaller, more granular parts. But at a high level, these three components need to connect very well with each other and need to be at the same level in terms of their ability to handle certain complexity. And what I mean by that is, for example, your quoting tool might be very well equipped to create detailed, complex pricing quotes that you have. But if your billing engine is not capable enough to be able to apply that complexity, then you won’t be able to bill correctly. Same goes for the third component.  

Behdad: 
Exactly. Because maybe we can just double click on some of the – without necessarily mentioning companies with respect – is some of the challenges that you face in light of those kind of three main areas that need to really function well. So for example, we have, let’s say, a situation where a the customer service team is really trying to fulfill a customer’s needs and and they provide certain services to them. If there isn’t a proper, well-functioning data capture system that you call it that really runs all the way back, is that a situation or challenge that you’ve seen yourself? And what kind of issues does that create?  

Priya: 
Yeah, that can definitely be an issue. One example of an issue that you can create is, let’s say a customer success team member is interacting with a customer, and they have agreed that the customer needs to activate a new product. They’ve done the contracting process and everything, and then the customer success team turns on the product. But if the right system is not in place to ensure that new product getting activated is reflected at all the backend points, so that you can actually start invoicing them for this new product as well then essentially it can create a situation where uh where your customer is using the product but your systems are not even aware of it and you’re not generating any incremental revenue from that usage so yeah.  

Behdad:
You mentioned earlier as well when we opened up this session that the payment industry is quite mature. So granted the discussion we have now, given the fact that we’re speaking multiple payment methods and oftentimes things are happening in real time, and that’s a big factor. And we’re speaking enormous amount of data transfers here into the trillions that we spoke about in multiple currencies, in multiple countries. Of course, what you want to have is as much of an automated system that can really connect the systems as you just explained. In whatever end they start, they should be able to communicate through the entire quote to cash. Is it so that companies within the payment sector are that mature or are you still seeing that there’s immaturity with regards to the data capture system?  

Priya: 
There is. I would say there’s a fair bit of immaturity as well. It depends on the nature of the company, the type of company we are talking about, certain geographies as well. So, yes, to answer your question, there is that, I would say, capability gap in the data capture and management systems.  

Behdad:
And why is that, would you say, Priya? Why is it so that there is such a gap? There must be good reasons for it.  

Priya: 
Look, there can be multiple reasons. I would say the two dominant reasons, in my opinion, are one is some companies have been using legacy systems, and these legacy systems can only evolve at a certain pace. They have definitely not kept pace with technology, the evolving needs of the industry, the customers. And it’s difficult to make changes in these systems and update them, upgrade them as well. And then the alternative of replacing them completely with something new, that’s a daunting task. So that almost never happens. So that’s the first reason. And the second reason, you know, companies as they get started, as they grow, the initial phases they don’t pay so much attention to these issues or to this specific area and then what happens is they keep like putting together some makeshift solution and work with it that serves the need at the time but then as they scale they again just keep putting band-aids on things and it keeps the system together, you know, let’s just say that. But then they reach a certain scale where they start seeing these issues. But by that time, there’s already, I mean, you are quite deep down that path. That system is handling a lot of things and making, again, similar to the problem with legacy systems, making a major change would take a lot more effort. So at that point, for some or the other reason, these decisions keep getting delayed. And then the end result is, yeah, you keep dealing with a suboptimal system and the implications of it.  

Behdad: 
Yeah. One can tell us that you come from experience when you speak about this, because similarly here, the observations that we’ve made with the number of clients is that those points glue very well, not just with the payments sector, even in the financial industry sector, we want to make it larger, in fact, to other industries too. I think the whole legacy system aspect is quite problematic is because it’s a factor if I play that back to you is that regardless if you would like to start fresh or not, you can’t because you have already a running business and you have to make sense with the existing infrastructure that you have. And since every system was built for its own operation, not to be able to necessarily liaise with other systems with different formats and different rules and so on. So that creates a huge problem, which leads me to the second question, which is interesting that growth kind of makes you forget the problem and you put on Band-Aid solutions, but eventually it will catch up with you. And this is a little bit what we’ve seen now in many, many industries, given the economic situation where it’s simply not so easy to get the same growth that you were before. But I think at this stage also, I want to take it back to something really important that you said and we discussed earlier on, is that even if you’ve been having growth with a very mature business model being usage-based, what you are witnessing now in the payment sector is that you need to be able to have multiple ways of offering it. Therefore, the conclusion of actually flexibility and agility is the holy grail.  

Priya: 
Yeah, yeah, completely agree. That is where I think the industry is headed. And this trend reflects itself or manifests itself in different ways, not just in the area of billing, but yes, in the space of usage-based billing and ability to evolve with times, customize that, it is critical.  

Behdad: 
And there’s good reason that many fear billing transformation projects because we’re looking at multi-year, oftentimes three to five year long projects where you’re dealing with, we refer to it oftentimes like an open heart surgery. You’re basically dealing with it doesn’t get more core for the company than that. Of course, in any ways, you can either do without or even just take it in pieces or chunks. That’s very appealing. Let me ask you, because you explained what you would expect for a well-functioning quote-to-cash system. What’s the best way to solve for this like if you would um address the issues what path would you go? 

Priya: 
To address the issues?

Behdad: 

Yeah if you want to if you would kind of set up a court to cash system that really serves the purposes we discussed today and based on your experiences what would be the key capabilities that they would need to have to really fulfill those needs?  

Priya: 
So I think the answer to the question would be different depending on the growth stage or the stage of the company and maybe customer segment focus as well. But again, generally speaking, to begin with, if I look at, again, the three key components, So if we start with a quote creation tool, so you need to, when you’re, if you’re in a situation where you’re trying to select among different options, you need to select, or I would select something that connects all the different pieces together. For instance, a quote creation tool is not just a quote creation tool that exists in vacuum. It also needs to communicate with some, a lot of other systems, not just, and not just your billing and invoicing system, but also, for instance, your CRM system. It needs to be a solution that can actually be the glue that it needs to, to support different parts of the organization. That’s one key requirement, but specifically in the billing context, I think I would have a detailed discussion or detailed review of the different capabilities and then map them against my revenue model or pricing model requirements. And then also think about, so right now, this is what I need, but then how do I think it will evolve in future, in near future? Because two, three, four, even five years down the line, I don’t want to have to look for another provider. So I would also take that into account. But yeah, at a high level, basically, that’s the process I would follow. And then accordingly, when I look at the billing and invoicing system options, I would again, go back to what are my pricing model requirements and how well does the system handle it? So basically, if I think about the decision framework, that is the decision framework. You take your current requirements into account, but also think ahead a little bit. Think about how you see this evolving. What are some of the things that are going to probably remain constant? But then what are the parts that might change? And will this solution be able to handle those changes? I think in this evaluation process, one thing that is not that commonly done but can be very useful is actually just do a run a pilot. It takes some effort, of course, but it’s worth it. Before going through full integration, just run a pilot, pick your most complex use cases, and run them through these systems and test how these systems handle those most complex use cases. And they should be sort of like a super set of all or most use cases you will see in terms of complexity. And if they can handle those, then they can handle everything. On the data side, I have little experience just evaluating solutions and trying to understand what the technical specifications should be. But also it’s a bit hard because you cannot really run a pilot for that kind of thing. It is going to require almost equal amount of effort when it comes to integration, taking it live and all that. So there, I would say, but the decision framework remains same. It’s just that the process of actually evaluating solutions against that decision framework, that would be different.  

Behdad:
If I take the liberty, Priya, and just to add a little bit on what you said is I think that regardless of no CPQ system, billing, ERP, or CRM system is necessarily built to kind of communicate flawlessly with any other system that’s just not what they’re built for so I think one of the one of the major challenges when if we look at the you called it the data capture system I think the term that you use is look at the requirements you have on the data that needs to flow and connect all the systems not just flow through because it’s not just one-sided, it’s actually the constant back and forth. So you gave great examples when you shared that if there’s a customer success team that turns on a service but that is then actually not fed back into all the other systems and specifically in the into the billing system that you can actually charge the customer properly. Or conversely, sometimes you might charge the customer incorrectly for something that they haven’t choose, which was your example of be mindful if you go down the customization road, you need to make sure that it’s completely like you need to have perfect data, if you will, if we speak those terms. But make sure that your back end is ready to support it because we all recognize, I think even personally, when we get a bill and we’re not recognizing something that we’re being charged for, we want that immediately fixed. These disputes that happen, suck resources from organizations and also create unhappy customers. These are exactly and in worst case maybe even result in cancelled services and so on. So yes I think that the on the data capture side and there are many good examples of companies that whether they use the term mediation or usage data management is something that we typically refer to it is that there are there are good good ways of solving for there are software out there to specifically designed to do this to offload the requirements and all of these systems speaking to each other it doesn’t really matter which format or business rules that they come with and make sure that the data is clean and it just works across the different systems which means you get a great delivery of service to a customer, you can adapt it you make sure that it is built correctly and so on.  

Priya:
No, I agree with that. I mean, yes. And I think the thing that you mentioned, that there are companies that are providing this kind of mediation service between your different systems to ensure that the right data flows back and forth between the right systems. So this is a requirement. But what I did not talk about is whether or my perspective on whether or how well are companies developing solutions to that effect in-house? And I think the answer to that is there’s a lot of room for improvement there. So I think if there is a third party solution that exists that can address that need, then I think a lot of companies would be interested in considering that kind of solution for sure, yeah.  

Behdad:
I think there are pros to building your own software, of course, because there’s absolutely a feeling of if we do it in-house and maybe we get a system to come and build it specifically for us, it’s customized, it’s perfect. But I think also we have some really interesting successful companies. If I just mention, Microsoft is one that I think most would agree is a fairly successful company with pretty strong engineering DNA. They’ve decided to use DigitalRoute software. And I think the reason is, yes, one, it’s more efficient for them. There’s nothing more or less than that, it’s more efficient for them. To me if a company like Microsoft can basically choose to throw as much resources as they want to into solving it themselves, if they chose to go down a certain route, it speaks at least a certain volume but regardless, my advice to any company would be just make sure like you said yourself look at your requirements, look at your current performance in light of where you need to be and make sure you do your external due diligence.  

Priya: 
Yeah. Also just to add to what you said I think uh you know we’re all we’re all aware of this this of this uh uh sort of conundrum or confusion between build versus buy, that decision is always hard but like you said Microsoft they have all the engineering resources in the world to throw at this problem but this problem probably is not, I mean, it’s not part of their core business model. And this is not something that they want to spend their time and energy on because it’s not just about building it. You have to continue to maintain it, update it, evolve, support the evolution of that solution. And that becomes a huge task over time.  

Behdad: 
Exactly. And that’s an excellent point as well. I appreciate you raising it because this was also something that we’ve seen from several other customers because it actually becomes much more costly when you have your homegrown solutions than you initially might realize you become locked into these endless loops of constantly having to fix and upgrade. Let’s also remember that something that we did not discuss so much today which is just compliance issues when it comes to data, especially like if we speak in the payment sector you need full traceability and auditability of every transaction and for that you need an absolute watertight system that works constantly so just a lot of requirements for any one company to try to make sure that their data capture system, as you refer to it, is constantly on par. So this is a great point, actually. Thank you for raising it. Priya, we have one question that I wanted to raise before we start to wrap up for today. This is a question from Mitali. The question here, as you can read on the screen, is whether maybe you can give an indication at least if there is revenue loss basically due to manual errors and issues that we’ve spoken about today. Do you have a sense for how much that could be?  

Priya: 
Yeah, I mean, so I can give you a rough number really. And the answer to this question is yes, definitely that happens. And the magnitude of loss really, and it can happen at, you know, any company, even for companies, of course, there’s a much higher probability of such a thing happening at a growth stage company or a scale up company, but it can happen anywhere. And the magnitude of loss will really depend on what sort of volumes you’re dealing with. So the larger the volume, the larger the magnitude of risk and potential loss revenue leakage from such errors.  

Behdad: 
We’ve done, of course, compiled a bit of research and we see on average somewhere between five to eight percent if we just aggregate across different industries. Our learnings is that which for some can be surprising even for mature companies it’s actually pretty bad you could meet companies that are in billions in revenue very successful but in fact the answer lies in what you already shared with us today earlier where you said that, what happens is that you have data just basically flows back and forth. Systems are not connected with each other. And people end up trying to manually correct and manage that data. And that never really works to perfection. So that means that there is data impurity. And then that leads to revenue loss. So five to eight percent, we’ve had examples of even higher number than that in some cases, depending on how deep the issues go, if we say so.  

Priya: 
I’m not surprised. Yeah, I’m not surprised at all.  

Behdad: 
And that’s maybe a good point to end on is that make sure that you don’t leave any money on the table for yourself and make sure that you don’t charge people incorrectly either. So that leaves everybody unhappy.  

Priya:
No, absolutely. This is literally free money that you’re leaving. I mean, you’ve already done the work for this and you’re just not taking it because you don’t know it’s there. Your systems, rather, don’t know it’s there. So yes. This is a revenue leakage that can easily be plugged and should be.  

Behdad:
Priya, thank you so much for the conversation today. I greatly enjoyed it. And also thank you very much for everybody tuning in.  

Priya: 
Thank you so much Behdad for having me and thank you to all the listeners.