Turning Fragmented Payment Data into Actionable Treasury Intelligence (Deluxe)

Craig Jeffrey: Foreign.

Nathan Dixon: Welcome to the Treasury Update podcast, presented by Strategic Treasurer, your source for interesting treasury news, analysis and insights in your car, at the gym, or wherever you decide to tune in.

Craig Jeffrey: Welcome to the Treasury Update podcast. I'm Craig Jeffrey, your host today, and I'm joined by with my guest, Nathan Dixon from Deluxe. And welcome to the podcast, Nathan.

Nathan Dixon: Thanks for having me, Craig. Appreciate it as always.

Craig Jeffrey: That's good. So our topic today, there's a long title and a short title. The short title is Turning Payment Data into Treasury Intelligence. The longer title is Turning Fragmented Payment Data into Actionable Treasury Intelligence. So there's a lot packed up in that. We'll dive into it and figure out what goes on. But, you know, I think as we start, Nathan, I would like you to contrast this data view that you've talked about before. Um, contrast that with a process view, uh, maybe in the context of value and needs. How would you describe that?

Nathan Dixon: Yeah, for sure. So, I mean, the traditional process view, right, you have, in terms of cash application, as we're going to be speaking to it, is the cache is coming in, right? You need to apply that cache. You have different workflows depending on whether you can apply that automatically, whether that becomes an exceptions, whether it goes to collections. So you kind of see that process view, um, and as the transactions flow through, you know, at the end of the day, you have, you know, I had a hundred transactions or invoices, sorry, that went into collections, I had a thousand that I was able to apply automatically. Um, I had 200 that became exceptions. So this is kind of like that process view you have basically like a conveyor belt. And as the transactions move through the conveyor belt, they stop at certain points. Um, and then after all is said and done, you're basically able to look at that data, um, on a section by section basis and say, all right, we have a ton of exceptions. Let's dig into one exception here and let's figure out what's going on. So you're very reactive, um, and it's hard to do at scale, right? Uh, you have a team of people basically working these exceptions. You have to kind of follow up with the team members that work them, look at the notes of what was done to the exception to basically be able to apply that cache. Ultimately, were you able to apply it? So the reasoning behind it takes investigation time. But as you go through that traditional process flow, you're ultimately applying that cash and you're able to gain some insight out of it, right? You can take a look at kind of like the really painful ones, you might be able to say, all right, this happened this month. I'm going to try and fix it with a solution or B solution. And the next time that comes in, hopefully you're able to handle that, or you're able to reach out to the customer or the payer to figure out what went on and how you were able to fix it. So that's kind of like that, as I typically see it as a typical conveyor belt or the traditional process view.

Craig Jeffrey: So how does the data view look then?

Nathan Dixon: Um, so data view, right, is kind of like the macro of it all. I'm able to not only look at all the transactions at one point as I've gone through the entire process, I can basically react at scale. I can very easily, without like a data science team, be able to pull out insights and trends and look at again, that data in the macro and say, all right, Ida, a thousand payers, 200 of my payers are part of, you know, X vertical industry. Um, they're all kind of showing the same issue. All their payments are kind of slipping by X amount of time. Is it a seasonal thing? Is there something going on in the industry? And then that can help you react at a much more, again, macro scale where you can apply a singular fix that can solve a lot of your issues above and beyond that. Rather than just, uh, kind of like that reactive perspective, you're also able to be proactive. So as the data's coming in, um, you can look at the data and with AI as a tool, basically there, you can look at it and very easily compare it against the historical data to say, hey, all this data's come in. We've had a thousand transactions this month. 200 of these show very similar issues to what you had last month. Before your team even starts to work these, we can take these actions on them. Rather than 200 of those payments going into an exception workflow, um, you're basically able to say, no, this cash can be applied. Here's the fix for it. This is what the issue was. We're able to very quickly look at all the data and say, this is the execution that needs to be done to rectify these issues. So it's two things, right? You're able to look at it at a much larger scale. So I don't need individual people looking at individual transactions. And I'm not only reactive, I'm able to be proactive with it. Because as the new data is coming in, I can action on it almost immediately. Whether it's Done in an automated fashion through the tools of AI or the suggestions of AI and then just basically waiting for sign off from a person. And you know that increases your cash flow, right? You have more cash basically ready right away. Um, what it also does though is it distills down the actual work that is manual. So again, I'm taking those 200 transactions, maybe there's 10 that really need a human touch. Um, so we can highlight those 10 kind of immediately have the people actioned on them, actioning on the important stuff and again not being slowed down by that bulk of the 200 transaction work.

Craig Jeffrey: So the conveyor belt view, as you were describing that I was thinking there's a long conveyor belt, um, where there's handoffs. It sounds like that view is you look at one piece of the process and you see here's posting here's. And then later down the process you see collection or you see other activities. Whereas the data view is this, you see everything summarized and can get at it. Is that, is that accurate or how, how would you fix me?

Nathan Dixon: So yeah, it's basically like it's all homogeneous, right? You're bringing in all that payment information all at once and you can basically see all of you in a single place. Um, as we'll talk a little bit later, right, you want to normalize that data, but with all that data being one spot, you can get like almost instantaneous metrics on the matching, right. And what was worked, um, by the AI side of it. So for me it's, you're kind of collapsed. Like you still have a conveyor belt, but it's collapsed where a lot of the work is done up front and then you have fewer steps afterwards where you may need a human touch. You might have a step after the automation which is just, you know, um, let's say there, let's say you're applying confidence ratings, right? So the matching or the AI is able to say, you know, the bulk of these transactions, we're able to match these with a 95% certainty. I have a few though that drop, you know, around the 80% confidence range. I just want you to review these, right? So a human might go in and they might just review them and say, yeah, that looks correct. That's still quicker than someone having to dig into each of the transactions, try to find all the different bits of information, try to find all the remittances. You brought all that together. Um, and then you're just approving what are those suggested matches. And then there's still likely you're left with a little bit left over, but it's better than working all 200 transactions for that day. If you're only left with 5, 10, which were very problematic transactions, it's still easier for your team's workload.

Craig Jeffrey: So, Nathan, that was certainly helpful. Uh, and I know one of the challenges that people face is there's data within an organization, but there's, you know, if we're looking at payments, there's usually data with a bank, with a third party, there's this whole process we have to get the data. And I know portals are really, they're a pain for many people. Um, how does the new environment help with, uh, that, you know, accessing data for sure.

Nathan Dixon: Right. Um, so traditionally a lot of this data, like you said, either you're logging into a portal, might, um, be your banking portal, might be an email portal where you're collecting remittances, might be something for your erp. So AI has really helped move forward some of the collection of these remittances. You know, there was a big change a while back where we moved away from SFTP transmissions for a lot of the files, um, which have the payment information, have the invoice information. Within the last five years, I would say we've seen a massive uptick in consumption of APIs, which is really great to see. Um, you get the data faster, um, you can reconcile the data, it's easier to validate. Um, and AI, um, has kind of taken it to the next step. Uh, what's really interesting, um, if you think about these remittance portals or email boxes, your erp, um, is these agentic agents, and specifically these headless chromium instances. What that is is basically they've given an agent credentials to one of these port, and the agent is logging on behalf of the actual user. Um, and it's really cool to see. Uh, basically that agent with those credentials is able to log in, pull in the remittances into kind of like a central repository, or work it directly in there. Um, and they're able to basically normalize the data themselves based on learned history. Um, and instead of the user having to go in, take a look at all these different portals, try and figure out what data elements match other data elements. You have an agent which is able to process this insanely quickly. Um, so it's really interesting to see, um, I've even seen some instances where we've been able to go into kind of like closed invoices. So we give it access to an erp, it's able to look at kind of like the historically closed invoices. How was the payment, or, sorry, how was the invoice closed? How was the payment applied? Were there disputes, were there deductions that were applied to the actual invoice? And it can make use of these elements in kind of future transactions. Um, and with a lot of the traditional cash application software, you'd have to make rules around this, right? You'd have to say, I have this discount code here. It can be applied in X scenario, but it's really hard to come up with a rule that covers your whole base. These agents, um, basically through confidence thresholds, are able to apply these in a much more proactive, uh, way. It's really sped up some of the cash application processes and reduced some of those exceptions. Um, even if it's not quite sure it can do it, uh, typically with a lot of these models, they'll have a confidence threshold that you can set, let's say 95% confidence above. I'm going to let the agent kind of apply it automatically to that payment, any remittances that it captures. But if it's able to capture some remittances, but it falls within, between, let's say 80%, 70% of a confidence that, yes, this is correct, it can surface that to you. So it's still done a lot of the legwork. Um, so it said, you know, I've captured these remittances, I think it applies to this. You know, I've looked at some kind of historically closed invoices. It's a similar scenario. Do you want me to apply it this way? So even though it didn't do the complete match, it still reduced a lot of that legwork, um, and then it learns from that. So if you say, yes, that's the match, um, going forward now, the next time, it can make use of that and use that again to do a match. So even if it's not perfect right off the gate, uh, with a lot of these systems we're kind of seeing it does a match pretty decent job right out the gate. As it learns over time, it's able to apply it more efficiently. And then after say six months of them running, they're running a 95% plus match rate, which is incredible to see. It's improved kind of the processes across the board, the data mapping side of it, the legwork to actually collect the remittances, bringing it all together and then making sure it can apply it effectively.

Craig Jeffrey: Despite it being called headless. It certainly sounds like it, um, it's doing a pretty smart, smart uh, set of tasks there and uh, you know, you were describing the human in the loop and it runs into a, into a challenge. So quite excellent description there. Partway through our discussion here, I'd love for you to do a quick introduction of Deluxe and what do you do at Deluxe?

Nathan Dixon: Yeah, for sure. Um, so I am um, director of Solution management. So here at Deluxe we like to think we offer products and services. Um, so our product org is called a solution Org. Um, I primarily run what's called R360 plus which is our integrated receivables and cash application solution here at Deluxe. Um, a lot of you might know Deluxe as a checking company. It's been around for 114 years. Um, and then over the past, I would say about 10 years Deluxe has been going through a digital transfer information. Um, so we've kind of taken a look at the checking product set, expanded our 360 plus, which is the product that I manage and my team works on, was one of those avenues where we put some investment in cash application is kind of like a core competency of that product. So that's something we've been really working on. Um, and I actually come from a bit more of a technical background in the hosting space. Um, but it's been really exciting for me to be able to hands on with a lot of these AI tools. So Deluxe was great at kind of adopting that side of it. We still run obviously traditional development, uh, been accelerating that with a lot of these AI tools as well.

Craig Jeffrey: Thanks for that. Uh, that background and there's some information in the show notes for following up with Deluxe or looking at their website. I wanted to shift to the uses and use cases of well that relate to turning fragmented payment data into actionable treasury intelligence. So taking just data that's by itself and making the process making the people more intelligent. Maybe you can talk through some use cases.

Nathan Dixon: Yeah, absolutely. So there's a few different things here. Right. I'd say the first thing is you've got to have kind of the data sanitation when you're running any sort of AI tools. Um, context is kind of the big thing. So when you're running an AI tool, it can basically only hold so much context at once. Um, and it has the understanding that you give it. So when you're running any, anything like that, you want to make sure that the data sets that you're using are normalized to not really a singular data model but like kind of a clean data model. Where there's a definition behind each of the fields. So when the AI is running against it, it understands this field that I've got here, this is the invoice field, this is what it's used for. Um, this is my payer field. You know, all my payer information is going to be assigned here and there might be an array of other fields behind it. But like the data sanitation is just, is a huge thing. Uh, if you're pulling in data and you're not normalizing it together as part of a singular set, the AI is going to get confused on how it should be applying certain things. So I would say, you know, first and foremost, the data's got to be clean. Um, you can use AI as part of that process. So, um, you know, back in the day, you typically have, if you're bringing in a new data source, you need to have somebody working that, right? Like you take a look at your core data model. I'd have this external source. I'm going to build a transformer or some sort of middleware, and as the data is coming into my repository, I'm going to transform, transform that. Um, and you know, that's a lot of work. Like if you're onboarding cash, um, application, for example, and you have a lot of behaviors at the company of how cash is applied, it can be difficult to kind of map that to a data mapping. So AI is also useful not only in the actual actioning itself, but in the implementation process, the setup process. Um, it can be used to assist kind of that data mapping and say, hey, I think this data set maps to this. Do you want to accept this? Um, so it can be used in that capacity as well. But making sure again that the data is sanitized is going to be key to the success of the tool. And if you have issues in the data, you'll start to see that in the output. Um, so even if you've started running and you think the data is clean, you start to see an issue, it'll kind of arise in the output of what the AI model is giving you, maybe in terms of the suggestions of matches or how it's applying the cache or what it's identifying as a difficult pair. Um, but that's kind of like the first, foremost step there, I would say, is making sure that data is clean.

Craig Jeffrey: Okay, so that's, if that's the foundational step. What are some of the uses of now you have clean data? What are some of the use cases for this idea of.

Nathan Dixon: Yeah, um, so one of the big ones we're seeing is kind of risk assessment. Right? Um, so say you have a thousand payers or you're looking to onboard a new pair. You can use the AI tools to look at, uh, let's say again, let's say I have those thousand payers and I it's able to identify trends in the data of who is a high risk payer. Um, so maybe you don't want to extend a certain payer, you know, a large amount of credit just because they've been identified as high risk. Um, it's great at looking again at the macro amounts of the data and identifying certain attributes that might be indicative of somebody that's, that's high risk. Maybe they're, they're always like to pay. It always ends up as dispute, things like that. Again, you would have an understanding of that with a manual team to some degree you might have this really problematic pair and everybody knows them. Um, but what the AI can do is it can look at the data of that specific pair, let's say, and then take a look at the rest of the data set across all the other pairs and see if similar conditions apply. And then if similar conditions do apply, they can say, hey, out of the thousand pairs you have here, about 100 of them kind of fall within this high risk template. So there's certain data elements that we've identified on the known high risk ones that also help apply to a lesser degree. Um, but that could help drive, you know, some of your business decisions. Right. Again, do I want to extend credit to them? How much business do I want to do with them? It could even be used externally, like say you want to bring on a new payer, like you have some new customers that you're looking at. It can be used to help identify ones that, you know, might be better to do business with things like that. So that, that's just one side of it on the risk. Um, but I see a lot of that in the industry now. Like basically it's almost kind of like a credit bureau, but it's internal to the AI tool and it's based off your own data.

Craig Jeffrey: So this could be, um, it identifies something, suggests reducing how much you might ship, for example, or it could trigger, hey, let's have a call and find out what's going on.

Nathan Dixon: 100%.

Craig Jeffrey: Yeah.

Nathan Dixon: Um, and it might even, you could even use it as part of the cash application process, right? Like say you have certain deduction codes that you might make available to your payer set or your customer set. Um, you could restrict some of those deduction codes or some of those dispute reasons based on that, that risk assessment as well. So we're kind of, there's definitely some players that are further along here. Um, and it's interesting to see how that data is being used in such a way. Um, but yeah, I would say that's probably the number one I get asked about currently in the industry.

Craig Jeffrey: I know that, um, there's a lot of uh, interest in use cases around forecasting cash flows. But I really wanted to focus on another area which you had talked about, like this idea of, you know, cache application, you know, as you're applying things and using some of the smarter tools, natural language, maybe you could go through a case study or an example of how, how that's transforming how smart we are with our processes.

Nathan Dixon: Yeah, absolutely. So it's interesting, right? You traditionally you'd have this large data set and you'd have like a data science team. Um, and you have to imagine you have your, your AR team or your IR team, uh, basically working with the data science team to try and pull out insights. Right? Um, so there's multiple layers that this requirements and requests have to go through. You know, at the end of the day you hope you, you get output that kind of makes sense for your business. Um, and, and like again that's, that costs money. Like large enterprises or corporates can do that. The smaller guys, not so much. So these AI tools, you know, kind of accelerate that process and, and give people who have the actual business knowledge the ability to use natural language. Basically what that means is I'm basically, you know, think about it like chat, GPT or claude. I basically get a text window, um, and I can type in what I want to ask the data. So I can say hey, what my forecast for this month, how much revenue based on the invoices I have going out, do I expect to come in? Um, and it can give you, you know, a visualization of that. Not just, you know, uh, a singular data element, but it can actually generate a graph and it can show you things like if it's coupled in with that risk assessment capability, it could show you what's low risk forecast and what's high risk forecast. So it could even show you variances based upon your actual payer set. So this, and this is done instantaneously, right? You no longer have to wait 30 days for a team to execute on and do the actual data science aspect of it. You're able to pull this information right out of the data set within minutes. So it's interesting to see, um, you're able to be, rather than purely reactive, you can be almost proactive in some elements of it. Um, and then you can use it in other ways too. Let's say, I want to ask again, out of my thousand payers, which ones are my high risk ones you talked about a little bit before. But you can use the natural language and the interface with the data to generate. Here's my call list of 10 payers this month. These were the problematic ones. We need to sit down and have a conversation with them, or we can show them how they're slipping and maybe, uh, making their actual payments. And that can lead to a conversation to either rebuild the relationship, shore that up, find out is there an issue on their side, um, and you can use that information to then rectify the issue going forward. Um, and even beyond that. Again, the AI has access to all these data elements. Um, at the macro scale you might be able to say something like eight of these 10 payers that are high risk, they're all part of the same industry. Is there something going on, you know, at the industry at large? Um, and you can bring in external data like that to, to help say, okay, this is just a seasonal thing. This is almost expected with this. Um, you know, you might see this on an annual basis during this season. You're going to have an issue in terms of how quickly these payments come in from these, you know, types, uh, of payers as part of this industry.

Craig Jeffrey: Interesting. So the, you know, you had mentioned the learning that takes place for logging into systems. And it's the same type of scenario it gets. How do you give it guidance to get better the next time? Right. It's doing a good job of analyzing an industry. Is there that same type of feedback loop or context?

Nathan Dixon: Yeah, absolutely. And there's a few different ways to do it, but like natural language is typically the best. Again, like there's, so there's, there's context, um, which is what an AI model uses for understanding when it's making queries. So what's interesting is let's say you have a team of 10 people and they all have access to an AI tool. You can create a context document that is preloaded into each AI, uh, chat. So when someone's starting a conversation, any context that one user might have is shared across to another chat window. And this is really interesting. So this allows kind of your users to all work from a similar place. Right. They all have a similar understanding of the payers. They all have access to the Same data. They understand the types of questions you might be asking and something they've learned with one user, um, can be used by another user as well. Um, so again I would say natural language is the most interesting way to do it. It's almost, and you kind of learned it as you use it more often. Um, like back in the days you were using Google, some people might say they have strong Google Fu. Right? I'm very good at using Google. I can always get the information that I want. I would say the ability to interact with these chat models using natural language is kind of a new skill. Understanding, you know, where the, where the weakness does lie but where the strength lie, um, I think is a skill people you know, should be leveling up and I think they're going to naturally as they use these tools. Um, but, but it's very, it's interesting to see, it's. Sorry, interesting to see when you have multiple team members working off the same data set.

Craig Jeffrey: I like your gamer definition of leveling up. Right. You gotta, you gotta, you gotta know, you gotta, you gotta, you gotta increase your skills in that area. That's, that's pretty good. Um, you know, one of the questions I'm sure that will come up and I just wanted to spend a little bit of time on it was data security and privacy. Right now you're turning these bots, these agents against the data. What are some of the key principles of data security and privacy?

Nathan Dixon: Yeah, this is a big one. Um, there's a few different ways to approach this. Um, so you can, when you have an AI model, it can be like an AI model that's external, right? So if you think of like ChatGPT, anything you put in the chat GPT, that's going to go directly to the Microsoft servers and that's kind of mixed in with all the other data there, right? You wouldn't want to be putting someone's payer information or credit or credit card information into anything like that. Um, so you can get kind of like models specifically uh, for a tool. So like say we self host a model. It's not something that's going to be going out to an external company. It's all kept in house so you can stand up models that way. There's also different uh, things called mcps, which are how models interact with different tools. I think it's model context protocol and you can have those also be used to filter data. Um, so if information is going into a model over the mcp, you can say hey, this question that I'm Asking is specifically for this pair and it can look at that specific slice of data. Um, so again, it's not inferring a response off a data set. It shouldn't have access to. Um, another way to kind of handle it, um, is if you air gap the model from the data. So if you think when you're using a UI yourself as a user, um, and you're logging into a portal, you're doing a search, that search is actually typically creating an API call. So when you do that search, it's shooting an API call off to the back end and then it's getting a response and it feeds it back to the ui. Um, what you can actually do with some of the models is you can not have the model touch the data directly. You can actually speak with a natural language to the model. And the model has such a great understanding of the APIs that it actually uses the existing API infrastructure there to send an API call to that data and it fetches the data that way. So in that case, your model itself doesn't actually have direct access to the data. So there's like a few different ways you can kind of integrate these natural language models. Um, that's actually one we've done personally because, um, in the industry right now, obviously AI is a fairly new thing and there's a lot of hesitation to introduce it into the payment space, specifically on the banking side. Um, so we've tried to offer a few different ways in which the models can interact with the data. Um, and I think just being completely transparent about what the data for is going to be key. Um, you don't want anybody getting burned on this and making sure you can offer it in a variety of ways I think is very important. Now, obviously, the more access it has to the data in a wider context, the more efficient, effective it's going to be. But, you know, data security is key, right? You have to make sure everybody on both sides of the table feels comfortable with it. Um, so I think offering a few different ways to do that integration are the big thing there, at least in the near term.

Craig Jeffrey: Yeah, that, that, that certainly is logical. You know, that principle of least privilege and principle of, you know, like you said, air gapping or separating it out. So if there were a problem, it's limited the damage that can be done. That's good for network security, it's good for using AI, it's good for general business practices. As we wrap up the discussion, I wanted to hear any final thoughts or pieces of advice that you would give to the Head of ap, um, uh, Shared Service Center, Treasury. Um, what would be something that you would want people to take away?

Nathan Dixon: Yeah, absolutely. I think the number one thing is just get yourself involved in the tools, right? Like you can sign up for a chat GPT account, you can sign up for a cloud account, and you can try out the tools. Now, I don't load any of your own actual company's data into those tools, but, um, what's really popular right now is making synthetic data. So if you know, you know that business and you know how your business works, the tools are very good at creating synthetic data. So giving it the use cases of, you know, what are the different conditions of an overpayment? What are the different conditions of an underpayment? What disputes do you typically see? Um, something I do personally when I want to test something out is I'll make synthetic data and it can create thousands and thousands of transactions within minutes. Um, and then as I'm going through and we're using some of our tools, we can load that synthetic data in. Um, so I say just the exercise of going through and using them the tools that way, digging deeper into what are some of the use cases you maybe don't see or you don't realize are actually happening to your business, that the tool is great at explaining that. I'd say it's one of the best teachers I've ever had in terms of learning kind of new concepts. Um, and being able to use it with synthetic data has been really key to the growth of the product that I work on.

Craig Jeffrey: Interesting. Um, you think about how the development of chess went. Everything was loading programs, people trying to make it smart by completely design. And then they did the gaming thing. So they made it so it could play games, play against itself millions of times. And it quickly surpassed the I'm a really smart coder approach.

Nathan Dixon: Exactly. Yeah.

Craig Jeffrey: Well, that was great. You know, get involved in tools, whether it's on your personal time or you could do that through work. Synthetic, uh, data. So hopefully everybody's every been leveling up their understanding with terms like mcp, synthetic data, um, all those, uh, great terms. Nathan, I really appreciate your time. This has been fun. Thank you so much.

Nathan Dixon: Anytime, Greg. Thank you so much for having me on. You've reached the end of another episode of the Treasury Update podcast. Be sure to follow Strategic Treasurer on LinkedIn. Just search for Strategic Treasurer. This podcast is provided for informational purposes only, and statements made by Strategic Treasurer LLC on this podcast are not intended as legal, business consulting or tax advice. For more information, visit and bookmark strategictreasurer. Com.