#354 Beyond BI: Decision Intelligence with Graphs with Jamie Hutton, CTO at Quantexa

Generative AI is transforming industries at an unprecedented pace. But as AI changes how you or your team work, one thing is clear: your skills also need to evolve. At DataCamp, we offer everything you or your team need to adapt and thrive with AI. Whether it's business users looking to get the most out of ChatGPT and Copilot, or developers and data scientists looking to fine-tune models, you can learn the entire AI skill spectrum on DataCamp. Power your AI transformation today. Start learning at datacamp.com.

Anyone who says you can totally eliminate hallucinations is unfortunately— it's not really possible, but you can minimize them to an extent where they're really a non-issue. Decisions made on context. That's what we really mean when we say decision intelligence, really resolving those down. So you've got one single view of the truth. That's the first step in the process. We call it entity resolution.

A big selling point of data analysis has been data-driven decision making. Where you use data to make better decisions than gut feeling alone. The next evolution is decision intelligence, where you optimise and automate decision-making. It's a fascinating field combining data science and AI, with a lot of worrying about data quality and data silos, and a smattering of process improvement.

So what we had to do was design the system from the ground up to work in that space of messy, disparate, and even intentionally manipulated data. And they've doubled the accuracy of their underlying decisioning models just by feeding in better context.

I want to find out what's possible with decision intelligence and how to achieve it. Our guest is Jamie Hutton, the CTO at decision intelligence company Quantexa. Jamie's in charge of building the decision intelligence platform, and the focus is on fighting financial crime and enabling regulatory compliance for banking, insurance, and governments.

Deep learning, great, but black box. You cannot use it in compliance and regulated use cases because you have to explain how the model works. So do you you can essentially turbocharge the LLMs by providing them with a graph-based context.

Let's find out how to make intelligent decisions. Hi Jamie, welcome to the show.

Hi Richie, how you doing?

Doing all right. I'm excited with the conversation. Now, to begin with, decision intelligence is a big buzzword at the moment, but is it just a new term for data-driven decision-making?

Great question. I mean, the first thing I'd say on decision intelligence, it's that pivot from what traditionally used to be business intelligence and decision-making into actually being able to make proper decisions. And I suppose the big difference between what we might have seen previously is decisions made on context. That's what we really, what we really mean when we say decision intelligence. It's all about when you make a decision about what you should do with a customer or prospective customer, not just deciding it based on the information that's directly in front of you, but the connection, the web of relationships between it. And that's what we really mean by decision intelligence.

Okay, so you've got a lot more information in the background in order to make better decisions. Can you give me an example of like someone you think does this well? Like, are there any companies where you think they're really good at decision intelligence?

Well, it's a relatively new field. So Quantex actually was one of the, they've only, the main analyst firms have only just released their magic quadrants and actually we're in the top right, which is where you'd hope to be. But it's a brand new segment. So the big players that you'd expect to see there are the ones that have been around for a long period of time and have lots of functionality. Really, it's the nexus of decision-making and analytics, graph-based decisioning, entity resolution. Those are the kind of things that all come together to make decision intelligence a key capability. And so, yeah, really that's where Quantext sits.

Okay. So a lot of different technologies involved in that. Actually, maybe do you want to break those down? Like what the different components do?

Yeah, I'd love to. So the first thing that we do when we think about decision-making is you've got to understand who the people, who the businesses, who those real-world entities are. That's what we describe as entity resolution. So if I've got a customer, Jamie Hutton, over here, and we also know that Jamie Hutton is a shareholder or director of Quantexa, that actually is really useful information. So when I'm deciding whether Jamie Hutton should be given a new product or whether he poses any risk, understanding that corporate relationship as a simple example is critically important. And it comes even more simple than that on entity resolution. Some of our customers, especially the big boys, will often have siloed systems. They'll have a Jamie Hutton over here, a James Hutton over there. They won't know whether these are fundamentally the same person or not. So entity resolution is that disambiguation. It's like working out who the real-world people, businesses, addresses, phones, emails, really resolving those down so you've got one single view of the truth. That's the first step in the process. We call it entity resolution. Okay.

All right. Uh, so I feel like this has been a persistent problem with a lot of, uh, businesses like, well, I guess for decades now, it's like trying to work out, well, you know, I've got 7 different customers who might be the same person or not, and then it's all stuck in different systems. So, uh, I guess what's the progress been made towards like solving this then?

Yeah. So it's a, it's a problem space that's been around for a while, but if I give you a bit of a scene set, um, some of the early solutions in this space were born out of MDM or master data management, if you're familiar with that. So there are lots of master data management solutions out there. And what they're very good at is where you have just duplicates, Jamie Hutton, Jamie Hutton, same information across many systems, they'll produce a single view. What we realized when we started Quantexa 10 years ago is unfortunately the world is not full of perfect data. In fact, it's quite the opposite. When you think about master data management, you're generally trying to get a single view of customer. Well, when we tackled this problem, we tried to make it a lot more broad than that. If you imagine for a moment you're a bank, yes, you want to know who your customer is, but you also want to know who's on the end of a payment. So who is that? Who's Jamie Hutton paying or receiving money from? Now clearly the amount of data you have on that counterparty is a substantially lesser amount of information and lower quality than the data you would have on a customer. The same is true when you think about third-party data. That example I gave of Jamie Hutton is a director of Quantexa. We have to get that information from somewhere like in the UK Companies House, or maybe Moody's, Dun Bradstreet, these sorts of data sources. And again, the richness of that data is never gonna be as strong as the data you would hold on customers. So the approach that we took, and I suppose the sort of the, the way that this has stepped on over time is it's gone from MDM, which was only about single customer view, into a single party view that can really encompass everything. Internal data, external data, structured, unstructured, both your customers, but also your suppliers, your counterparties, any of those other third-party pieces of data, which naturally have lower quality and lower completeness. And I guess that's a big evolution. The other thing that we would also say is that we also came at this from the perspective of finding bad guys in data is one of our first use cases for the platform. So imagine for a moment, Richie, you are a criminal. You might be Rich, Richard, Richie on multiple different records. You are gonna intentionally change your details to evade basic matching, right? So what we had to do was design the system from the ground up to work in that space of messy, disparate and even intentionally manipulated data. So that's, I suppose, how we've evolved that first bit of the puzzle I describe as entity resolution.

And just for the record, I am inconsistently Richie Cotton or Richard Cotton across the internet, but not, not for crime purposes, I should add.

I'm exactly the same, right? So I'm Jamie, but all my mates call me Jim, and on my passport it's James. So there you go. 3 examples.

We should start a crime syndicate. Yeah. So it sounds like there are sort of some implications for fraud detection here and things like that. So are there any other business benefits advantage you have from like this better quality of data then?

Yeah, I mean, this is one of the really key things. We, we try to deploy a platform like Contexa to service many different use cases. So some of the examples are everything from the bad to the good. So if we start with the bad, this will be people who could be potentially defrauding you, taking money away from you. Let's say you're an insurer, it could be someone trying to submit fraudulent claims. A bank, it could be somebody trying to get a lending product and disappear with it. These are great examples. Then if you think about compliance as a sort of still in the bad zone, I suppose, money laundering, great example. You know, you have to be compliant with the regulation in this space and being able to get that view of who is Jamie, what's Jamie doing, allows you to understand whether that payment that I'm receiving or sending makes sense. Does it make sense or is it potentially got some element of risk associated with it? So those are the sort of like bad use cases. Then you've got the middle use cases, which would be decisioning around, let's say, what products I give somebody and what lending I give them. Them, et cetera. So a bank credit risk, you would describe it as. In insurance, it might be underwriting, deciding how much your premium should cost. These are risk decisions that are being made. And again, providing better context to those is critically important. And then you can get onto the positive side of the business. So on the positive side, you would have things like new customer acquisition. So can I and should I be doing more business with Jamie Hutton? All contacts are limited. Should I offer them additional products? These are the sort of positive use cases. And you've got everything sort of on the gamut, uh, in between, if that makes sense.

Uh, okay. Yeah. So, uh, it sounds like there's like a lot of kind of core business, uh, processes and they're gonna be more efficient once you've got the, the better data in there. You mentioned, uh, that a lot of businesses struggle with data silos. This seems like a, a universal thing. How are you solving this problem of like different data stored in different systems?

Yeah, exactly. So the first thing that we do, and this is quite unique to Kontaktsat, lots of other systems, you have to take the data that exists in the customer's source system and you have to map it into a vendor-specific schema. And of course, this takes a long time. It's error-prone, not really adding any value. You're just mapping data. So what we did was we turned the problem on its head. We point our system at the data in its native structure. The system automatically tags it. It's like, oh, that's a name, that's an address, that's a phone number, that's an email, tags it automatically. And that then allows that information to be brought into the system and resolved without that big transformation approach. So that really does cut down the time to value and the amount of manual work that has to be done when you're bringing in the data into a resolution context, an NZU resolution process. So that's sort of, I guess, step number 1. And step number 2 is then being able to deal with that messy, disparate, and incomplete data that I mentioned a little bit earlier on on the podcast, where traditionally, if data was poor quality, you couldn't put it in the system. Well, actually, Quantix is designed from the ground up to work with poor data quality. So that really helps also get the data in more quickly and easily.

Okay. And where does this sit, like, relative to the rest of your tech stack? Like, because I get the feeling, like, data warehouses are getting bigger and bigger, and you kind of throw absolutely everything in there. And is this like a layer that sits on top of the data warehouse? Is it like something that comes later in the pipeline, I guess?

Yeah, it sort of sits inside it almost, I would say. So the idea with our software is what we don't do is rip all the data out of the data lake, the lake house, whatever your architecture may be. We don't rip it out and process it. What we do is we push our application into that environment. So, you know, many of our customers will use Databricks or they use Snowflake or they'll be on one of the major cloud providers. We take our software, run it where the data exists, and we essentially publish new data products, data assets into that same data, data lakehouse type environment.

Okay.

All right.

So it's basically working alongside the data warehouse or lakehouse rather than replacing it. And you mentioned that the strength here is around dealing with poor quality data. I mean, this is probably very exciting. You are having a lot of analysts who are like, oh man, data quality is always terrible. It's like an unsolvable problem somehow. So yeah, talk me through like, What sort of like terrible data can you deal with and like how do you solve this like low quality data problem?

Yeah, absolutely. So the way that we do this is rather than sort of expecting a really nice join key or connector between lots of data sources, what we do is we look at every piece of data across the whole record. So we, I describe it as we substitute data quality for data quantity. I.e., what we do is we match on as many attributes as we possibly can. In order to get that best possible view. And what that means is if on one record I've got a slightly different date of birth to another record, well, as long as there are other attributes tying me together, then we can be pretty sure it's the same person. So as I say, substituting data quality for data quantity. We also have quite a lot of things built into the system that will deal with things like intentional manipulation. So the classic example that we talked about a moment ago, Richie, Richard, Jamie, James, Jim. These are synonyms of one another. The system knows that, it learns that from the data that we've deployed it on. So it can ultimately bring those things together. That's baked into the platform. And we also are able to deal with even more complex examples. My favorite example is often like transliteration of names. So if you're a, imagine you're a Chinese national, you write your name in Chinese. Obviously when you come over to the UK, you're not, you can't use the, see the Chinese scripts anymore. You have to romanize it. And you want to be able to. For many of our customers, it's important to be able to match cross-lingually. So we even support things like that. So it allows us to deal with that poor data quality or even data that's, you know, to a human, completely different, but actually to the machine makes it the same.

Okay. Yeah, certainly. I can imagine that once you're translating between different alphabets, then yeah, you can end up with like slightly different spellings each time. And that can be a real data quality nightmare.

All right.

So it seems like a lot of these are kind of technical solutions to data quality problems. Are there also, um, process things that you need to do in order to get these kind of the, the better quality or more consistent data in order to make the better decisions?

Yeah, you know, a lot of our, it's really interesting when we first deploy Quantexa at most of our customers' site, the first thing that we find is in addition to that's the risk we're looking for or the opportunity we're looking for, we also find a load of data quality challenges. Um, and that is actually really powerful for our customers to know, and we've, we've actually got a way of deploying our platform in a more master data management style, which is essentially the ability for us to report those data quality issues and therefore automatically remediate them upstream and fix them upstream. You can, of course, and in many cases you should have a human in the loop as part of that process. So you need to make sure your systems and processes are in place to be able to deal with the output of something like Quantixa, both from a, once I've found the risk or found the opportunity, I need somebody to look at it or I need to automatically decision it. But equally perhaps on the data quality side, you can find some really great insights that come out of applying this type of technology into almost data remediation programs, if that makes sense. Okay.

So I love the idea of having a feedback group there so you can report on data quality issues. Who does that though? Because often it's not going to be a data analyst who is spotting the problems. It's going to be like some sort of end user. So how does that flow work then? Because you can have different teams involved.

It's so different by organization, to be honest, Richie. You know, some of our customers are, they're a bit more mature in this space and they literally have data steward teams. So there are teams who are there to fix data and to remediate quality. Others will put this in the hands of the endpoint. Let's say if you're a bank, the relationship manager to correct and manage the information that comes out of it. So. It really is, there's no right or wrong answer here. Some teams will centralize it and fix it at the center and have central remediation teams. Others will push it to the edge and ask their, you know, customer-facing teams to help remediate. Okay.

Do you have a sense of like the pros and cons of each of these setups, like whether it's centralized or whether it's federated?

If you're dealing with small numbers of really high, you know, high-value customers, then probably pushing it out is going to be the better approach. When you're dealing with, let's say, retail, you might have millions and millions of customers, probably centralizing is going to be the more efficient approach. So it's probably those sort of trade-offs that you're looking for.

Oh man, I suppose like once you're dealing with that situation where customers are reporting issues, you then got like more data quality issues again, because I mean, people will complain about whatever. Talk me through like, how does that even work? Like, how do you deal with all these like nonsense that customers tell you? I mean, there's gonna be some signal in there, obviously, but yeah, how do you deal with it?

You know, some of our customers will actually push the questions out to an end user or to, sorry, to the customer and to allow them to validate themselves directly. So, you know, let's take a simple example. I've got two Jamie Huttons in my system, but I believe they're one. And on each of those records, I've got two addresses. Well, actually, if you've got that inconsistency, you could try and work out what the latest information is, do it centrally. You could get your customer relationship manager to ask the customer. But you could also send out something that says, we need you to revalidate your address, please just provide this information in a more self-serve automated way. So there are pros and cons with all of these. The latter is, you know, probably the least intensive for the end, for the bank or the, for the customer who's dealing with the data. But for the end user, they might be getting loads of these requests. So, you know, you've got to balance this with how much you're interfering with the customer flow versus you could have done centrally without even touching customers. So these are the balances that people have to trade off, I guess. Okay.

Yeah. I mean, certainly I have definitely seen on some apps where they're like, oh, we're not sure we've got your details right. Can you just check that these are all up to date and all that sort of thing?

Okay.

That makes sense. And do you have a sense of like what the sort of benefits are going to be once you resolve this? Like, have you got a sense of like how much you can quantify like some sort of uplift from having the better systems in place here.

Yeah. Well, look, I mean, the thing about this is it's fundamental to the businesses that we work with. You know, if I take— there was one organization who, of course, on this I won't be able to name, who had, they believed, 120 million customers approximately. When we ran entity resolution, we realized that that was only about 70 million real-world entities, people and businesses. Now that's quite a delta, isn't it?

That's like 50 million made-up customers. That's— Gonna be a shock to your investors, right?

Exactly. So this is the sort of thing. So now, now you take that and you feed it into all your business processes. You can treat those customers more holistically because previously they might have had a mortgage product over here, a banking product over here, a wealth product over here. You can now treat them as one. So clearly that's better customer experience, better customer service, and you can make a better risk decision based on that customer because you know everything about them. So you've got all of those benefits right through to as I mentioned before, finding the bad stuff as well. You know, if I've got a good view of who Jamie is and every touchpoint that he has, you can really unlock some huge benefits. And some of, some of the examples I'll give in the past, we've had systems where previously people have been trying to make a decision based on one record at a time or just basic information about the customer, and they've moved it to an entity or graph. I'll talk about graph in a minute, maybe level, and they've doubled the accuracy of their underlying decisioning models just by feeding in better context. Because if you know who I am and who I relate to, you can ultimately make a better decision.

Okay, that's pretty amazing. And I can see how it's very easy for businesses or managers to like kind of lie to themselves about like what the state of the business is if they don't have the right data about the customers, about their, I guess, all their finances and the rest of these things. Okay, since you mentioned graphs, graphs are like the hot technical topic at the moment. Talk me through like, what, how'd you make use of graphs in this case?

For sure. So I guess our first part of it is you can't really have a good graph unless you've done that entity resolution upfront, right? If I've got 3 customers that are all different customer IDs, Jamie, James, and Jim, and I don't know they're the same, then they're different nodes in my graph, right? So the first thing you have to do to get a sensible and meaningful graph is to do entity resolution. Once you've got that, what you tend to find, Richie, is you've probably heard of the 6 degrees of separation or 6 degrees of Kevin Bacon, sometimes people say it. This is really true in real-world data. And actually, I'd argue it's a lot less than 6 in most of the data that we see. And this is that everything connects to everything. Take an example of, let's take insurance just for a simple example. How many customers have had their cars repaired by Autoglass? Loads, right? Because they've had windscreen repairs. Is that an interesting link? No. If you think about banking, how many of your customers have paid the local tax authority to pay their taxes or a utility bill provider? The answer is millions. Is that interesting? Not really. So what you have to do is you take that massive graph that comes out of entity resolution and you need to analyze it. You need to break it up and understand which links are strong and which are just coincidental. And that's ultimately what we do. So we can analyze graphs in a couple of different ways. One is you can build a graph around every entity in the system. You could say, here's Jamie's graph. Here's Contax Unlimited's graph. And what we're doing is we're taking those starting points and essentially just stepping out, but following the strong links, not the coincidental ones I mentioned earlier. So that's a, a really classical technique when you're looking at graph analytics. And then the other approach is you turn the problem on its head. You don't have a starting point, but you have a pattern you're looking for. I'm looking for this sort of cyclical flow of funds, or I'm looking for a corporate ownership structure that that looks a bit like this. So I don't know where the starting point is. I don't even know if I've got any examples of this in my data. And the system goes away and finds all the relevant examples that match the criteria you're looking for. So you can do it in those sort of two ways. We describe it as egocentric, starting at a particular start, or more pattern-based where you're looking across the whole system. And ultimately, by leveraging graph analytics, why do we do this? We do it to make better decisions. If you can understand who is Jamie, who does Jamie know, then you've got a much better idea of whether Jamie's risky or has a new opportunity that you should be going after.

Absolutely. And I've seen some like examples of cool analysis where you just look at like who's been like contacting who in terms of like phone calls or like messages or whatever for like crime syndicates. And you work out like who's at the top just because of this. Like graph analytics is like, is wild. The kind of answers you can get out of things that you wouldn't expect just from sort of connections between things rather than any real information.

100%. You know, if I, if I talk about one of the use cases, we do a lot of work with government. We actually were the system behind the COVID loans fraud detection. So the Home Office used Quantexa to find where essentially back in the COVID days, people took out lots of loans with the intention of never paying them back, often using shell companies, if you're familiar with that, companies that basically don't do anything. They didn't do anything, suddenly they get a loan and guess what? The money never comes back. And Quantexa was ultimately the graph technology underpinning that to say, well, it looks like this is a It isn't just one person who's taken a loan and run away with it. You've got an organized criminal gang, a criminal network connected together, taking out these loans and ultimately not paying them back. So yeah, great example use case. We've got lots of sort of governmental use cases as well as the sort of commercial side that I've talked about earlier.

Okay. I feel like I'm learning a lot about how to do crime in this episode. Actually, maybe beyond that, are there any kind of other sorts of business data that you might want to store in a graph format?

Yeah, so when we think about data, again, you'll love— obviously if you're a commercial organization, you're talking about your customers, you're talking about the relationships they have to other data. So in banking, it'd be payments. In insurance, it would be the claimants who you're claiming with, just taking those examples. So all of that data goes in, but you generally want to augment it with third-party data. So the most common sources you would bring in, things like corporate registry, you know, Companies House in the UK or Dun Bradstreet in the US. These are great examples of data sources which can add some significant value. If you think about it, you know, if you want to establish how did Jamie make money, how did an individual make their money, often most of the time it's through the businesses that they're associated with, right? So having an understanding of that helps you understand source of wealth. But also if you think about it from a bad perspective, if you wanted to launder loads of money and get loads of money through the system, You're probably unlikely to do that on your retail bank account. You're probably going to use some kind of corporate entity to achieve that. So yeah, bringing in that sort of data can help both the positive and the negative really quite well. And then you'll always have other sources that are going to be relevant to specific use cases. Like when we're doing financial crime detection, there are watch lists, there are hot lists. When you're doing things like compliance, you want to have the politically exposed persons list so you understand relationships to political parties. These are the sorts of extra data sources, and each use case will have its own set of data, if that makes sense, that's relevant.

That's really interesting, and I hadn't really thought about the idea of politically exposed people. This is like people who are going to be blackmailed or whatever, and you want them to go into your, I guess, your crime risk list.

Also politically exposed people, there's just certain extra handling that a bank needs to do, or an organization needs to do once they know they have a PEP. So in some senses, doesn't mean that they're risky, but they do need to handle them differently. So actually being able to just simply match to that list and know the exposure is one of the key parts of it.

Okay, that's fascinating stuff. And so, all right, we talked about the entity resolutions is like working out how you go from the poor quality data to good quality data. We've got the context graph, which is going to go from we've got data to this is going to provide something useful. What's the final step to getting some analytical result there to we can make a decision. How do you, how do you serve that last step?

That's right. So that's where I guess DI, that's the decision piece, right? So why do we do all of what I've just described? Why do we resolve the entities and build the graphs? We do it so that we can make better decisions. And so what we're doing in the decision-making piece, we're applying just standard analytical tools and techniques. This will be everything from the most boring thing, which would be simple rules, right through to complex deep learning models. It can be anything in between. Right? All different types of flavors of analytics. And we try to be agnostic, right? We use the right tool for the job. There's no one-size-fits-all for this stuff. Just taking a simple example, deep learning, great, but black box. You cannot use it in compliance and regulated use cases because you have to explain how the model works. So there are different models that will work for different, different use cases. What do we do? We put better data into the models. It really is simple as that, Richie. You know, if you can put a view of who is Richie and who does Richie connect to and know with within the data and you feed that into the model, the model's got more to, to go on. It fundamentally understands it has a model of the real world. The context graph is a model of the real world. It's people connected to businesses, connected to addresses, connected to phone numbers. It's a model of the real world. So if you can feed that into the analytical model, it just has so much more data to go on and it can make a much richer decision. So if I give you a couple of examples, you know, if I was looking for risk, if I find a high density of risk on a graph, like I've got 50 people all connected together and lots of them are scoring for lots of risky reasons, then that network, that highly likely everyone on that network has got an elevated set of risk. Greg's another great example in the risk space. If you have a card or a, you know, a bank, bank account which you don't do normal transactions on, you're not shopping, you're not going to Amazon, you're not paying utility bills, you're not doing anything normal, right? That's okay. I mean, people can have multiple cards. But if you have a network of 50 people and not a single one of them is doing anything normal, that's probably not a real network. That's probably a fake network in order to get banking products and potentially do money laundering or fraud. So just giving that example and then flip it on the other side. We do a lot of work around uncovering new business opportunities. So if you already imagine have a banking relationship with Quantexa Limited, but your wealth division doesn't have any associations with the major shareholders of that company, and you can see Quantexo is a highly performing business, then that gives you a nice warm lead, doesn't it? Because you can contact your existing customer Quantexo and say, hey, we'd love to offer some services to your shareholders. And it works in the exact reverse. You know, if you've got a wealth relationship with a particular individual and they suddenly spin up a new company, surely you should be offering them banking services. So you can see how you can use that same context graph to empower a decision on the bad side as well as the good side, if that makes sense.

Okay.

Oh, wow.

So, uh, it sounds like then this is going to generate lots of opportunities for cross-selling, upselling. So, uh, you can expand your business, I guess, more easily that way. Uh, so it's a growth engine in that sense.

Is that right? Exactly. It could be used either way, right? Find the bad, find the good. Okay. All right.

And so a lot of the stuff you seem to be talking about, um, uh, sounds a bit like context engineering, which is one of the hot topics in AI at the moment, is providing more context for the models in order to get better answers. Do you want to talk me through the relationship and how it feeds into AI use cases?

Yeah, love to. And this is, I guess, where over the last few years things have changed so dramatically. You know, LLMs are unbelievably powerful at understanding the data that they were trained on, which is all the publicly available data. But of course, what they won't have out of the box is access to your proprietary internal data for obvious reasons. So what a lot of systems did a year, 2 years ago maybe, was they did this RAG where basically all the LLM's doing is querying out to a set of data and pulling back the relevant records into its context window so that it can hopefully make some kind of decision. And that works to an extent, but I suppose what we do is we flip the problem slightly on its head rather than the LLM calling out to 10 different disconnected systems and retrieving a whole load of, you know, potentially hundreds, thousands of values back and trying to disambiguate it itself. We have a graph. So rather than doing RAG, we do Graph RAG. We describe it. So when you ask a question like, I don't know, do we bank Jamie Hutton? And are there any new business opportunities connected to Jamie Hutton? That's a simple question. To achieve that question in reality on disconnected data is unbelievably complicated because firstly, you gotta know who Jamie is. If I say who, who's Jamie Hutton, it could be 5 Jamie Huttons in the system. There could be one Jamie Hutton. So straight away you need entity resolution. Once you've then got that, you then need to be able to understand the relationships. Well, if you've got a graph, what you can do is you can basically say, what do we know about Jamie and who does he connect to? You can say, well, actually there were 3 Jamies here. They, which one do you mean? Do you mean this guy or this guy or this guy? And then you can pull the relevant record. And once you've got that, you are now grounded in the graph. You are, you are, you are in a particular place on the graph. And to say what other opportunities are there is a very simple graph traversal. It's like step out, step out, find the relevant things. So what we've experienced is you can essentially turbocharge the LLMs by providing them with a graph-based context. And that's exactly the sort of sweet spot that we sit in. We are that context engine. We then integrate with whichever LLM our customers choose to use.

Okay, so it sounds like this is going at least some way towards solving the problem of hallucinations with large language models. So you can reduce it. Again, do you have a sense of like, is this a complete solution or is this reducing it? Like, how much sort of benefit do you get?

The really nice thing about the hallucination question, that hallucination goes up the more you throw into that context window and the more you essentially dump into that window and hope the LLM's gonna work it out for you. By providing a graph that says, here is Jamie and here is who Jamie knows, and that's basically a provided piece of information, you can tell the LLM only answer based on the data that is in the graph that I'm providing you with, which dramatically reduces hallucinations. Now, with an LLM, anyone who says you can totally eliminate hallucinations is unfortunately it's not really possible, but you can minimize them to an extent where they're really a non-issue. And what we've got as part of our product, we do quite a lot of this with some of our customers, is we have a set of test suites, which basically, you know what the question is, you know what the data is, you know what the expected answer is, you can actually measure how accurate you are compared to, you know, when you switch models, or when you change the configuration, you can say, did that actually improve things. So being able to validate this stuff is almost as important as being able to actually answer questions, if that makes sense.

Absolutely. I'm sure, particularly for in a regulated environment, again, you mentioned before the idea that you have to have some kind of explainability around like any decisions you're making. So having that, I guess the graph in the background is going to give you that sort of backup, like, did it answer the right question or not? This is helping if you've got the AI helping you answer the questions, make decisions, like, is there still a role for humans then in decision-making? Or can you basically just like outsource all your thinking to AI?

At the moment, it's a real mix. And I think what I would describe it as is the agentic systems are making humans a lot more efficient and more effective, which obviously would sort of conclude therefore that you probably need fewer humans to do the more laborious and mundane tasks. But it's also opening up new opportunities, right? I mean, in the example I just gave, uh, with, uh, acquiring new customers, these sorts of things. Often that is done as best with a human touchpoint, right? You know, if I'm trying to acquire a brand new business for a banking relationship or a, you know, a new high net worth individual as a new banking relationship, a human needs to be in the loop. And what I suppose we think is that if you can free up your humans to do more of the high value work and get the machines to do more of the mundane heavy lifting, then you're in a much better place. What was the old way of doing this? The old way, if I wanted to find more Quantexes, like let's say Quantex was the model company that you wanted to do more business with. You would just search for companies that were like same size, same industry, same, you know, same geographies. You'd search for them and then cold call them. I mean, that's very, very low success rate, right? Uh, or email them, cold email. You know, you're not gonna get good, uh, response rates with that. So you probably had quite a lot of people doing a lot of things which didn't actually materialize in value. Well, with decision intelligence and with the graph powering this stuff, you can actually say, well, here's a lead, but it's a warm lead. Like you already have someone in your organization who knows one of these touchpoints. You already have a banking relationship with them. All you need to do is reach out to them and get a warm lead, a warm intro. So you can get through more work with the same workforce, um, if you want to keep your headcount the same. Or for the more mundane stuff, you can do more with less people. Like, you know, that's the situation that we're in. The other thing that's worth pointing out, obviously in regulated industries, you can't, you can't just outsource this all to the machine. There are expectations from the regulator on humans being in the loop and validating a lot of this stuff. So again, you can make the processes as efficient as possible and effective as possible, but you can't entirely cut out the human from, from the loop. Uh, and to be honest, nor would you want to. At this stage.

Okay, yeah, certainly I can see how just completely outsourcing any decision-making to AI, it's gonna be very risky. Like, it's gonna go wrong fairly quickly, I think, at the moment. Maybe that's what we keep for the future, and for now, humans are quite worthwhile. All right, so let's talk a bit about how you go about getting started with this. Suppose you're like, okay, let's do decision intelligence better.

What's step one? Yeah, look, it's really interesting. It depends sort of where you are on your maturity and your data estate, right? Some of our customers are, they want to treat Quantexa as just a context engine, basically something that creates the entities and the graphs and essentially creates data products. If you're familiar with data products, all they are is a, you know, a set of data which is curated, high quality, you know, really well documented and available for consumption for lots of different use cases. That's what you sort of might describe a data product as. And a lot of our customers will just take Quantex's data assets out of the end of our system and just publish them into their own existing data estate. And then they can pick them up and use them in their downstream use cases. So if you are an organization who's quite far down their data journey, quite mature, then ultimately you can take our data products and leverage those pretty quickly and easily. Other of our customers really want us to solve what we describe as a vertical problem, and they want to solve a pointed use case. So they, they're like, I just want some more leads. Can you help me with that? Or I just need to find a particular type of money laundering or fraud risk. Can you help us with that? And that's where we deploy not just the data products, but also the detection models on top and the end-to-end case management and workflow that would go around that. So, you know, it depends where you are as to where you start. Many of our customers will start with the horizontal. They'll say, you know, we just want to have essentially better trusted data for decision-making. Contexa just enriches that environment. Others will come to us and say, I've got this gap and I just need to solve this one problem. And we'll come and solve that one problem. But the nice thing is when we do that, we always are thinking about the other one, if that makes sense. So we would put in the system to solve the fraud problem that they might have. But actually they've then got a reusable data asset that they can also use for other things. And that's kind of the one of the key benefits of the system. Okay.

So I do like the idea of starting with a specific problem solved, like whether it's generating more leads or like reducing the amount of fraud, uh, like rather than trying to like kind of boil the ocean, do everything at once. It sounds like, do you have to solve some of your data infrastructure issues before you go in and, and get to this point where you can do decision intelligence? Or is it like trying to get to decision intelligence is going to solve your data quality problems?

Yeah, that's, that's the thing is I've had customers talk to me about this in the past where they're like, well, we can't do this because our data quality is too poor and we need to get it to a certain level. And to an extent, I hate to say it, but it's almost like that's a, that's a promised land that you might never reach. You know, there's always going to be things you can do to improve your data quality. So the way we pitch it is flip the problem around. Make the best use of the data that you have today in the quality that it may exist in. It may not be perfect, but put it a different way. Can you get value from your low-quality data? 100%. You can get a whole load of truckload of value coming out of leveraging something like decision intelligence technology on top of fairly rubbish data. You can get a huge amount of value. That doesn't mean you also at the same time Don't do any data remediation programs. Don't fix your data estate. So it's a sort of dual stream, right? Get some value straight away by leveraging decision intelligence. In the parallel, continue to improve your data estate and actually use your decision intelligence platform to help work out where you want to spend your dollars on improving your data estate. But it's not a prerequisite. Okay.

So I like that you're trying to figure out what the end goal is and then you try and build something and if it doesn't work, that's going to give you some good feedback on what's broken and what needs fixing.

You know, we've, we've had examples where our customers said, I'd— again, I'm, I'm trying to investigate this type of fraud, and we've, we've almost sat with them and said, well, what is your investigation process? What do you do to decide whether this is good or bad? And the moment you see them disappearing off outside of any data system that they have internally within the organization, you, you can realize that there's other parts of their investigation process which aren't captured, aren't present within the data that they have. So then you need to think about, okay, well, should that form part of my data estate, as an example. So you can sometimes work it almost backwards, like, like you're saying, we know what the business problem is, we know how people are solving it today manually, work backwards, what data would you need to more automate it? Okay.

And for people who are interested in a career in this area, is there like a decision intelligence analyst role in the same way that you have business intelligence analyst?

Wow, because it's such a new and emerging space, I'm not sure you'd find many jobs on the online job market, which would talk about it. But the skills you need are pretty similar to lots of the other ones that you'd have. If you were a data engineer and data scientist, those are the sorts of skills that somebody operating a decision intelligence platform would typically need. Having some level of graph understanding. So, you know, if you've previously done some graph modules at university, if you're coming out of grad school or similar, these are, you know, these are the sorts of skills that that would be always useful for decision intelligence type of technology. All right.

So is it kind of a lot of your standard issue data science, machine learning science type stuff, and then a little bit of like that network analytics, graph analytics on top of that?

Yeah. Yeah. Decision intelligence is ultimately bringing together multiple different things that have already existed for a period of time. It's bringing together decision-making, analytics, AI. It's bringing together graph, entity resolution, all of those into sort of an end-to-end. So that, so, you know, it's the same sorts of skills that you need for any one of those individual building blocks.

And are there any soft skills you need? It feels like for making decisions there ought to be, like, uh, I guess some critical thinking in there as well.

For sure. And a little bit, when we deploy our product projects, we often will have business analysts and people who will be experts in the field that you're trying to solve. So we're trying to, uh, uncover fraud. We have a whole load of people who really understand how the fraud is perpetrated and therefore can turn that into the decision scenarios, the detection logic, the graph patterns that ultimately will detect it. So there is a level of, you know, business knowledge that you really need in order to be able to configure these systems in the right way to actually spot the risk or the opportunity. Okay.

Yeah, certainly I can see how domain knowledge can be essential to make sensible decisions. I guess just finally, do you have any advice on how to get started with decision intelligence? Like, yeah, how do you get better at this stuff?

Yeah, look, I think from our perspective, it's about finding the right partners, you know, having a good data strategy, data platform on which to build all of this stuff. You know, the nice thing about what we do is we try and be relatively agnostic to the data platform that the customers have chosen, whether it's Databricks, Snowflake, you know, Azure, AWS, GCP. We operate on all of them, but having some kind of strategy around where you're going to land your data, where you're going to publish data products, and how you're going to govern and look after that data is obviously a great prerequisite. And then what you ultimately need to do if you're building decision intelligence is you need those key building blocks I was describing. You need a way of doing entity resolution, deduplicating. You need a way of applying graph analytics at scale at large volume. You need a way of deploying and managing an ongoing way analytical models that are actually making those decisions. You'll need an AI framework if you're going to leverage LLMs. You'll need to be able to integrate Quantecia or any other technology with your LLMs so they can get the value of that context graph. So these are some of the, I guess, the building blocks that you kind of want to have in place when you're thinking about decision intelligence.

That was a surprisingly long list. It certainly seems like there's a lot more there going on in order to get to the successful thing. But I guess you build these things up one at a time. You know, it doesn't have to be done all at once.

Correct. And look, most, most customers nowadays have some kind of data environment that they're, they're already leveraging. So really it's about filling in the gaps of things that you don't have.

Oh yeah. Like if you don't have a data warehouse yet, then you know, that's kind of step one, start like putting your data somewhere and then otherwise you've got nothing to be intelligent about. So just to wrap up, I always want more people to learn from. So whose work are you most excited about right now?

Well, I have to say the, um, generally the world of LLMs is moving at an unbelievable pace. We're pretty excited about, uh, at the Anthropic world. We've really gone all in on Claude within my own R&D environment. And, uh, I'm really excited to see where this goes. You know, we, um, we're seeing that some of our best engineers are becoming 10x engineers from what they were previously. But what we need to do and the challenge that that, you know, my team faces. How do we make everyone the best? So how do we level everybody up? So, you know, I think that is an industry-wide challenge that everyone's facing at the moment. You know, the absolute superstars can pick this stuff up, learn it quickly, and become unbelievably productive. But how do you make— how do you make this more achievable and accessible to a wider range? So, you know, I'm really excited about all of that at the moment.

Absolutely. Yeah. And, uh, I'd say Claude, definitely the model du jour, and it's, it's fantastic But I'm gonna make you follow up on that thought. Like, how do you get everyone, uh, to be that high-performing individual?

Ultimately, I think you've got to learn from your best, and you've got to encode it back in practices, processes, agents. You know, essentially take the learnings, the best learnings from the best people, and make it part of the standard development process so that everyone does it. It's the normal way of developing a feature. Um, it's the happy path rather than You know, at the moment, as things have evolved, it's an optional path. People can do the old way, they can do the new way. I think over the next year or two, you're going to find that the way is to leverage AI throughout your development. So I think that naturally, therefore, need a lot of stuff that you don't want everyone to be doing their own thinking on this stuff. You want to learn the thinking and push it back in so that everyone gets the benefit.

I'd love that idea of you find your champions within your organization, you share those best practices and just have it go viral, I guess, around your organization. Nice.

Exactly. Yeah. You don't just share them. You actually make them part of the process. You make tools that do all this stuff automatically. You make agents that follow the right pattern. So yeah, absolutely. That's the, that's where I think we're heading.

Wonderful.

Yeah.

Exciting times. Uh, thank you so much for your time, Jamie.

Thank you, Richie. Really appreciate it. Mm-hmm.