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

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 are a key capability. And yeah, really that's where context sits. 

Richie Cotton: Okay. A lot of different technologies have more than that actually.

Maybe, do you wanna break those down? What the different components do? 

Jamie Hutton: Yeah, I'd love to. So the first thing that we do when we think about decision making is you've gotta understand who the people, who the business is, 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 Quanta, that actually is really useful information. So when I'm deciding whether Jamie Hunch 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. We'll 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. 

Richie Cotton: Okay. Alright. So I, I feel like this has been a persistent problem with a lot of businesses.

I guess for decades now, it's like trying to work out I've got seven different customers who might be the same person or not, and that it's all stuck in different systems. I guess what's the progress been made towards, like. Solving this then. 

Jamie Hutton: Yeah. So it's a problem space that's been around for a while, but if I give you a bit of a scene set 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. What they're very good at is where you have just duplicates. Jamie Hutton, same information across many systems, they'll produce a single view. 

Richie Cotton: What we realized when we started Quanta years ago is unfortunately the world is not full of perfect data.

In fact, it's 

Jamie Hutton: quite the opposite. 

Richie Cotton: When you think about master 

Jamie Hutton: data management, you're generally trying to get a single view of customer. 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 wanna 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 qu.

We have to get that information from somewhere like in the UK company's 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 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.

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, how we've evolved that first bit of the puzzle I describe as entity resolution.

Richie Cotton: And just look at, I am inconsistently Richie or Richard across the internet. Not for crime purposes. I should add, 

Jamie Hutton: I'm exactly the same, right? So I'm Jamie, but all my mates call me Jim, and on my passport is James. So there you go. Three examples. 

Richie Cotton: We should start with crime together. Yeah. So it sounds like the some implications for fraud detection here and things like that.

Are there any of the business benefits you have from like this better quality of data then? 

Jamie Hutton: Yeah, this is one of the really key things. We try to deploy a platform like on taxa 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, money laundering, great example.

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 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, what lending I give 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. Can I can I, and should I be doing more business with Jamie Hutton or QUT are limited?

Should I offer them additional products? These are the sort of positive use cases, and you've got everything on the gamut in between, if that makes sense. 

Richie Cotton: Okay. Yeah. It sounds like there's a lot of kind of core business processes and they're gonna be more efficient once you've got the better data in there.

You mentioned that a lot of businesses struggle with data silos. This seems like a universal thing. How are you solving this problem of like different data stored in different systems? 

Jamie Hutton: Yeah, exactly. So the first thing that we do, and this is quite unique to axa, lots of other systems. You have to take the data that exists in the customer source system and you have to map it into a vendor specific schema.

And of course this takes a long time, sero 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 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 are bringing in the data into a resolution context into resolution process.

So that's step number one and step number two 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. Actually, context is designed from the ground up to work with poor data quality.

That really helps also get the data in more quickly and easily. 

Richie Cotton: Okay. And where does this sit like relative to the rest of your tech stack? Because I get the feeling like. Data warehouse are getting bigger and you throw absolutely everything in there. And is this like a layer that says on top of the data warehouse, is it like something that comes at later in the pipeline I guess?

Jamie Hutton: Yeah. It sits inside it almost, I would say. So the idea with our software is. What we don't do is ripple the data outta the data lake, the lakehouse, 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. Many of our customers will use Databricks or they'll 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 lakehouse type environment. 

Richie Cotton: Okay. Alright. It's basically it is 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, this is probably very exciting, but having a lot of analysts who are like, oh man, data quality is always terrible. It's like a, an unsolvable problem somehow. So yeah. Talk me through what sort of like terrible data can you deal with and like how do you solve this like low quality data problem?

Jamie Hutton: Yeah, absolutely. So the way that we do this is rather than 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, IE What we do is we match on as many attributes as we possibly can in order to get that poss best possible view.

And what that means is if on one record, I've got slightly different date of birth to another record 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. 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 ize it. I know we, you want to be able to, from any 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. Yeah, true. A human completely different, but actually to the machine makes it's the same. 

Richie Cotton: Okay. Yeah, certainly. I can imagine that once you're translating between different alphabets, then yeah, you can end it with like slight different spellings each time and that can be a real data quality nightmare.

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

Jamie Hutton: Yeah. A lot of our, it's really interesting.

When we first deploy Quanta at most of our customer's 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. And that is actually really powerful for our customers to know, and we've actually got a way of deploying our platform in a more mass data management style, which is essentially the ability for us to report those data quality issues.

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 Cortex, 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 enormous data remediation programs, if that makes sense.

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

Jamie Hutton: It's so different by organizations to be honest. Rishi some of our customers are they're a bit more mature in this space and they literally have dex data steward teams. So there are teams. 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 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 customer facing teams to help remediate. 

Richie Cotton: Okay. And 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? 

Jamie Hutton: If you're dealing with small numbers of really high, high value customers, then probably pushing out is gonna be the better approach. When you are dealing with, let's say retail, you might have millions and millions of customers. Probably centralizing is gonna be the more efficient approach.

So it's probably those sort of trade offs that you're looking for. 

Richie Cotton: 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, people will complain about whatever. Talk me through, like, how does that even work?

Like how do you deal with all these nonsense that customers tell you? There, there's gonna be some signal in there obviously, but Yeah. How do you deal with it? 

Jamie Hutton: Some of our customers will actually push the questions out to to, to an end user or to, sorry, to the customer and to allow them to validate themselves directly.

Let's take a simple example. I've got two Jamie Hudsons in my system, but I believe they're one. And on each of those records, I've got two addresses. 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. There are pros and cons with all of these. The latter is, probably the least intensive for the end for the bank or the for the customer for.

Who's dealing with the data, but for the end user, there's, they might be getting loads of these requests. You've gotta 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, 

Richie Cotton: okay. Yeah, and we certainly have definitely seen on some apps where 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 what the sort of. Benefits are gonna be once you resolve this.

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? 

Jamie Hutton: Yeah, look, the thing about this is it's fundamental to the businesses that we work with. If I take, there was one organization who, of course on this I won't be able to name who had they believed million customers.

Approximately. When we ran Entity Resolution, we realized that was only about million real world entities, people, and businesses. That's quite a delta, isn't it? That's, yeah, 

Richie Cotton: like million made up customers. That's gonna be a shock to your investors. 

Jamie Hutton: Exactly. So this is the sort of thing.

So then 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, or 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 are based on that customer 'cause 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. If I've got a good view of who Jamie is and every touch point that he has, you can really unlock some huge benefits.

And 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. 'cause if you know who I am and who I relate to, you can ultimately make a better decision. 

Richie Cotton: Okay. That, that's pretty amazing. And I can see how it's very easy for businesses or managers to like, lie to themselves about what the stake of the business is, if they don't have the right data about the customers, about their, all their finances and the rest of these things.

Okay. Oh, go on. Since you mentioned graphs, graphs are like the. Technical topic at the moment. Talk me through what how'd you make use of graphs in this case? 

Jamie Hutton: 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.

If I've got three customers that are all different customer IDs, Jamie, James, and Jim, and I dunno, they're the same. There are 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, once you've got that, what you tend to find Richie is you've probably heard of the six degrees of separation or six 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 six in most of the data that we see. And this is everything connects to everything. Take a, an example of, let's take insurance, just for a simple example. How many customers have had their cars repaired by auto glass 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 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.

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 QU limited graph.

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 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 and looking for this sort of cyclical flow of funds. Or I'm looking for a corporate ownership structure that looks a bit like this. So I dunno where the starting point is. I don't even know if I've got any examples of this in my data.

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. 

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

A 

Jamie Hutton: hundred percent. 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. Use Quanta 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 Quanta was ultimately the graph technology underpinning that to say it looks like this. It isn't just one person who's taken a loan and run away with it.

You've got a, an organized criminal gang, a criminal network connected together taking out these loans and ultimately not paying them back. Yeah, great example. Use case. We've got lots of sort of governmental use cases as well as the sort of. Commercial that I've talked about earlier. 

Richie Cotton: 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? 

Jamie Hutton: 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, in banking, it'd be payments. In insurance, it would be the claimants who you are 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 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. 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 gonna use some kind of corporate entity to achieve that. 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 gonna 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. 

Richie Cotton: That's really interesting. And I haven't really thought about the idea of politically exposed people. This is like people who are gonna be blackmailed or whatever.

And you want that to go into your, crime risk list. 

Jamie Hutton: Also politically, I suppose people, there's just certain extra handling that, that a bank needs to do or a, 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. 

Richie Cotton: That's fascinating stuff. And alright we talked about the NC 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 gonna go from, we've got data to this is gonna provide something useful.

What's the final step to getting some analytical result there to we can make a decision. 

Jamie Hutton: 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 end season?

Build the grass. 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 pro tool for the job and there's no one size fits all for this stuff. Just taking 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, if you can put a view of who is Richie and who does Richie connect to and know within the data, and you feed that into the model's got more 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, if I was looking for risk, if I find a high density of risk on a graph, like I've got 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 is, has got a high, an elevated set of risk.

Greg's another great example in the risk space. If you have a card or a, a bank account, which you don't do normal transactions on, you're not shopping, you're not getting your Amazon, you're not paying utility bills, you're not doing anything normal. That's okay. People could have multiple cards.

But if you have a network of 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 where QU are limited, but your wealth division doesn't have any associations with the major shareholders of that company and you can see QU is a highly performing business, then that gives you a nice warm lead, doesn't it?

'cause you can con contact your existing customer contact and say. Hey, we'd love to offer some services to your shareholders, and the, it works in the exact reverse. 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 a good side, if that makes sense. 

Richie Cotton: Oh wow. It sounds like then this is gonna generate lots of opportunities for cross-selling, upselling. You can expand your business, more easily that way.

So it's a growth engine in that sense, is that right? 

Jamie Hutton: Exactly. It could be used either way. Find a bad, fun. Good. 

Richie Cotton: Okay. Alright. And a lot of the stuff you seem to be talking about 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 wanna talk me through the relationship and how it feeds into AI use cases? 

Jamie Hutton: Yeah, love to, and this is I guess where over the last few years things have changed so dramatically. 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 outta the box is access to your proprietary internal data, for obvious reasons. So what a loss of systems did a year, two years ago maybe was they did this rag where basically all the l and m'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 different disconnected systems and retrieving a whole load of, 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 bang 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 five Jamie Huts in the system. There could be one Jamie Huttons. So straight away you need entity resolution. Once you've then got that, you then need to be able to understand the relationships. 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, actually there are three Jamie's here. They, which one do you mean? Do you mean 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 in a particular place on the graph. And to say what other opportunities are, there is a very simple graph to rehearsal.

It's like 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 with our context engine. We then integrate with whichever LLM our customers choose to to use.

Richie Cotton: Okay. So it sounds like this is going at least some way towards solving the problem of hallucinations with large language models. You can reduce it. Again do you have a sense of is this a complete solution or is this reducing it? How much a benefit do you get?

Jamie Hutton: The really nice thing about the hallucination question, the hallucination goes up, the more you throw into that context window, and the more you essentially dump into that window and hope, the LL m'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. We have a set of test suites, which basically, you know what the question is, you know what the data is and you know what the expected answer is. You can actually measure how accurate you are compared to when you switch models or when you change the configuration, you can say, did that actually improve things?

Being able to validate this stuff is almost as important as being able to actually answer questions, if that makes sense. 

Richie Cotton: 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.

Having that, I guess the graph in the background is gonna give you that backup did it answer the right question or not? This is helping if you, you got the AI helping you answer the questions, make decisions. Is there still role a role for humans then in, in decision making? Or can you basically just outsource all your thinking to AI 

Jamie Hutton: at the moment?

It's a real mix and I think what I would describe it as is the agent systems are making humans a lot more efficient and more effective. Which obviously would conclude therefore that you probably need fewer humans to do the more laborious and mundane tasks, but it's also opening up new opportunities.

In the example I just gave with, acquiring new customers, these sorts of things often that is done as best with a human touch point, right? If I'm trying to acquire a brand new business for a banking relationship or a a new high Netwealth 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. The mundane, heavy list lifting, then you're in a much better place. So what was the old way of doing this? The old way? If I wanted to find more contacters, let's say contact 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, same geographies.

You'd search for them and then cold call. That's very low success rate, right? Or email them, cold email. You're not gonna get good 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. With decision intelligence and with the graph powering this stuff, you can actually say here's a lead, but hit a warmly.

Like you already have someone in your organization who knows one of these touch points, 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. You can get through more work with the same workforce. If you wanna keep your headcount the same or for the more mundane stuff, you can do more with less people.

That's the situation that we're in. The other thing that's worth pointing out, obviously in regulated industries, 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.

Out the human from the loop. And to be honest, nor would you wanna at this stage. 

Richie Cotton: Okay. Yeah, certainly I can see how just. Completely outsourcing any decision making to ai. It's gonna be very risky. I get it's gonna go wrong fairly quickly. I think at the moment. May. Maybe that's what we keep for the future and for now where humans quite worthwhile.

Alright, so I, let's talk a bit about how you go about getting started with this. Suppose you. Okay, let's do decision intelligence better. What's step one? 

Jamie Hutton: Yeah. Look it's really interesting. It depends where you are on your maturity and your data estate, right? Some of our customers are they want to treat Quanta 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, a set of data, which is curated high quality, really well-documented and available for consumption for lots of different use cases. That's what you might describe a data product as. And a lot of our customers will just take context as 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 in their downstream use cases.

So if you are. If you are a, 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 a, what do we describe as a vertical problem? And they wanna 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.

It depends where you are as to where you start. Many of our customers will start with the horizontal. They'll say, we just want to have essentially better trusted data for decision making context that 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. 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. Actually, they've then got a reusable data asset that they can also use for other things, and that's the, one of the key benefits of the system.

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

Trying to get to decision intelligence is gonna solve your data quality problems. 

Jamie Hutton: Yeah that's the thing is I've had customers talk to me about this in the past where they're like 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 promised land that you might never reach.

There's always gonna be things you can do to improve your data quality. So the way we pitch 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?

%. You can get a whole load of truckload of value. Coming out of leveraging something like decision te 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. The parallel, continue to improve your data estate and actually use your decision intelligence platform to, to help work out where you want to spend your dollars on improving I improving your data estate, but it's not a prerequisite.

Richie Cotton: Okay. So I like that. Trying to figure out what the end goal is, and then you try and build something and if it doesn't work, that's gonna give you some good feedback on what's broken and what needs fixing. 

Jamie Hutton: We've had examples where our customers said, I'd again I'm trying to investigate this type of fraud, and we've almost sat with them and said, 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 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, should that form part of my data estate as an example? So you can sometimes work it almost backwards 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?

Richie Cotton: Okay. 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? 

Jamie Hutton: 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 decisions 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 are coming out grad school or similar, these are, these are the sorts of skills that would be always useful for.

Decision intelligence type of technology. 

Richie Cotton: Alright, so is a lot of your standard issue data science, machine learning science type stuff, and then a little bit of that network analytics, graph analytics on top of that. 

Jamie Hutton: 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 same sorts of skills that you need for any one of those individual building blocks. 

Richie Cotton: And are there any soft skills you need, it feels like for making decisions, there ought to be like I guess some critical thinking in there as well.

Jamie Hutton: For sure, and a little bit. When we deploy our product projects, we often will have business analysts, some people who will be experts in the field that you're trying to solve. So if we're trying to 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 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. 

Richie Cotton: Okay. Yeah, certainly I can see how domain knowledge is, can be essentials to make sensible decisions, just finally Japanese, advice on how to get started with decision intelligence. Yeah how'd you get better at this stuff? 

Jamie Hutton: Yeah. Look, I think from our perspective, it's about finding the right partners, having a good data strategy, data platform on which to build all of this stuff. The nice thing about what we do is we try and be relatively agnostic to the data platform that, that the customers have chosen.

Whether it's Databricks, snowflake, Azure, A-W-S-G-C-P. We operate on all of them, but having some kind of strategy around where you're gonna land your data, where you're gonna publish data products, and how you are going to govern and look after that data is obviously a great prerequisite.

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 gonna leverage LLMs, you'll need to be able to. Integrate Quanta or any other technology with your LLM, so they can get the value of that context graph. So these are some of the, the building blocks that you wanna have in place when you're thinking about decision intelligence.

Richie Cotton: 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, it doesn't have to be done all at once. 

Jamie Hutton: Correct. And look most customers nowadays have some kind of data environment that they're already leveraging.

So really it's about filling in the gaps of things that you don't have. 

Richie Cotton: Oh, yeah. If you don't have a data warehouse yet, then you know, that's start like putting your data somewhere and then otherwise you've got nothing to be intelligent about. Just to wrap up I always want more people to learn from.

Whose work are you most excited about right now? 

Jamie Hutton: I have to say the generally the world of l LMS is moving at an unbelievable pace. We are pretty excited about at the philanthropic world. We've really gone all in on, on Claude within my own RD environment and I'm really excited to see where this goes.

We we are seeing that some of our best engineers are becoming. x engineers from what they were previously. But what we need to do, and the challenge that, my team faces is how do we make everyone the best? So how do we level everybody up? I think that is an industry-wide challenge that everyone's facing at the moment.

The absolute superstars can pick this stuff up, learn it quickly, and become unbelievably productive. But how'd you make, how'd you make this more achievable and accessible to a wider range? I'm really excited about all that. 

Richie Cotton: Absolutely. Yeah. And absolutely Claude, definitely the model du jour and it's fantastic stuff.

But I'm gonna make you follow up on that thought. Like, how do you get everyone to be that high performing individual? 

Jamie Hutton: Ultimately, I think you've gotta learn from your best and you've gotta encode it back in practices, processes agents, 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. It's the happy path rather than, 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 gonna find that the way is to leverage AI throughout your development.

I think that naturally you therefore need a lot of stuff that you don't want everyone to be doing their own thinking on this stuff. You wanna learn the thinking and push it back in so that everyone gets the benefit. 

Richie Cotton: I love that idea of you find your champions within the new organization. You've, you share those best practices and just have it go viral, around your organization.

Nice. 

Jamie Hutton: 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 why I think we're heading. 

Richie Cotton: Wonderful. Yeah. Exciting times. Thank you so much for your time, Jamie.

Jamie Hutton: Thank you Richie. Really appreciate it.