Name: [EMEA/NA] Ask Me Anything with Quantexa Solution Architects
Uploaded: 2026-09-23T15:16:20.490Z
Duration: 22 min 40 s
Description: [EMEA/NA] Ask Me Anything with Quantexa Solution Architects

Transcript for "[EMEA/NA] Ask Me Anything with Quantexa Solution Architects": Lovely. So hi, everyone. Thank you so much for joining us today. My name is Sophie, and I'm a senior community manager here at Contaxa. I'm delighted to welcome you to today's event. It's our ask me anything with our solution architects. And today, I'm joined by Farid, Karl, and Chris. I'll ask them to introduce themselves in a moment. But before we get begin, just a couple of housekeeping points for myself. So to start with, the use of AI note taking tools is not permitted during the session, so please do refrain from using them. After the event, we'll be sending out a short feedback survey, and we'd really appreciate it if you could take five minutes to, complete this. Your feedback helps us to continue to deliver valuable sessions for you and your organizations. And this is an interactive session, so we'd love to hear your questions, whether it's about career development, day to day working, industry solution expertise. Please do send them in. If we can't answer them today during the session, we will reach out to you directly afterwards, to make sure you still get the answer. And so with that, I will pass over to Farjit, Carl, and Chris to introduce yourselves. Do you wanna go first, Carl? Sure. So I've, I'm Carl. I've I've been at Quantexa since November 2017. So coming up on my ninth quaniversary as we call it here. I started as a data engineer at Quantexa, in The UK where I worked for a couple of years and then moved over to The US as we were, as that area was growing and moved into architecture in 2020. I've worked with, I think, a couple of the people on the line actually, who I'm seeing in the room. I've worked on a number of accounts across, AML, master data management, and KYC. So yeah. Broad broad knowledge. I suppose most recently, I've moved into the deployment capability lead where I'm essentially focusing on how simple we can deploy context and how we can make that, as easy as possible for clients. I'll pass on to Farshid. Thanks, Carl. My name is Fashid. I am also a solutions architect in with Contessa for nearly six years. Based in. Australia. I am also looking after the Australian New Zealand portfolio in APAC region. And, also, I am responsible for streaming a real time solutions in, globally in, a, in delivery function. That yep. I think that that's that's a good reduction. Chris? It's Hi. I'm Chris Worley. I've been at Quantex for nine years about Central America, and I run our global architecture practice. Brilliant. Thank you very much all. So to get started, we had a couple of questions come in via the architect's user group on community from Gurus. We'll start with those. But, please do post any questions into the chat as we go through, and we can get answering those afterwards as well. So the first one is around AI and competitive differentiation. So as agenda k I, gen AI, and graph technologies continue to mature, how does Contaxa see its long term differentiation in areas such as NT resolution, network analytics, and investigative workflows? And what role will AIML play in that evolution? We've seen several banks increase investment in AI graph analytics and internal data products. And as a result, some are exploring in house entry resolution capabilities. How does Contessa view this trend, and what innovations is it making to ensure the platform remains the preferred choice for enterprise scale energy resolution and network intelligence? I can pick that up if you like, Sophie. Lovely. Thank you. Cool. There's a few bits in there. I suppose I'll start at the technology end and then, work up to the wider ecosystem end. So I suppose one thing I'd say is our opinion my opinion and our opinion is that GenAI itself is not a good solution for entity resolution. Putting all the data you want to entity resolve into an AI model is a very expensive and slow way to do things, and what you need to do is be able to work at large amounts of data. Because sort of however much data you have, you want to be working with a large amount of context to get all the value you need to out of that data. So we want deterministic tools that can work on big data. Now what we do do, Contexo, is use AI models to develop to develop those, particularly to develop how we pass data across multiple countries, how we generate test data to ensure that our NC resolution is really, really good out the box. And we think that's that's exactly the place we'd want to do that. But more widely, my view is that what if you have a GenAI and an Agencia k I ecosystem, what you really need is a trusted foundation of data on which to base that. If you are the the I think something that you'll we're gonna start hearing more and more about is context layer. Because if you're gonna have AgenTic AI, you need a context layer for that to draw its information from. We have the ability to to draw information externally, and, obviously, most of those can effectively search the Internet. But, actually, what you most want is your internal corporate information to be feeding into that in a way that's trusted, in a way that's linked, and in a way that you can really understand what's in that data. And so that is where I think Contactsa fits in very well because it can provide that trusted data foundation on which you base all those other use cases. It. Varsha Dukkad, did you have anything else you want to add to that on? It's done. It's lovely. So then next question, again, from Gary that came in was around platform efficiency and cost optimization. So while Quantexa continues to enhance its functional capabilities, large scale deployments can still be can still be commute per computer and storage intensive. What is Quantexa's roadmap for improving platform efficiency and reducing the overall cost of ownership for enterprise I'll take that one. So I think it's it's. it's important to recognize that, with Contacts, the context layer that Chris just mentioned, essentially can be shared across all of the use cases that you pick up as a as a client. So with the ingest of of data into entity resolution and graphing, we can produce data products that are then shared across the business. So it's ultimately designed as a solution where you produce something once and then share that whether that's with an AI tool or with a, any of the downstream feeds like into KYC or into your money laundering processes. There are, of course, optimizations as as we work as we go through. Some are driven by development via AI and some are driven by, development in the in the old school manner. So we're always looking for efficiencies there. One of the more recent and recent, I mean, in the past few years, areas include, streaming of data into the system. So looking at whether the right solution for your system is ultimately a a batch solution, if it's produce if it's producing data weekly or monthly, or if we are looking for a more real time solution in the, the time of, seconds or minutes, then you could look at whether they, whether having a message queue and a streaming solution is the right option. Pause that. Perfect. Anything to add to on Varshaet or Chris? Lovely. That's the thing. And then our final question from Gary today was around future architecture and customer value. So looking ahead, how is Contessa evolving its architecture to improve precision explainability and business outcomes while reducing the amount of customer led tuning required to meet regulatory and operational expectations? Cool. I'll pick that one up. I suppose one of the things about Contexra is that we we understand that every customer has fundamentally different data, And that's not that we they have diff all customers have different data because it's in a different format. It's because there are different things like data quality challenges, but much more importantly, there's different actual behaviors within that within that data. And so at what is normal in one country or one organization is abnormal and and interesting in another one. And, hence, that's why the cost the tuning per deployment is so essential. Now so I suppose what we're looking to do here is not to reduce the amount of tuning, but to increase the ease of that tuning. So that includes, things like Fusion UI to enable much easier, a much faster iteration cycle so that we can make changes around entity resolution and test those really easily. That includes things like ER tuning notebooks, scorecard tuning notebooks so that you have a very nice data analytics based framework that enables you to identify if the system is behaving as you'd want to and and identifying interesting things, and the outputs really match what's happening in the real world. And and this is all around, as you say, improving precision and making sure that's clear. I think our UI is very well focused around explainability. The outcomes that we get are very have a very clearly explainable scorecard based on the the behaviors we see, and all of that drives to getting the best business outcomes. So I think as I say, I think it's it's about doing rather than less customer led tuning, it's about more customer led tuning, but giving our developers the tooling to make that as quick and easy as possible. Brilliant. Thank you, Chris. So please do, yeah, continue to ask your questions, post them in chat for us. We're very happy to answer whatever we can. Kind of carrying on from the previous question though, what is on the road map that we should be excited about, especially, from the architect's point of view? And how does customer feedback, help to shape that? I'd love to pick this one up. I think that that one of our biggest pieces of customer feedback is that the effort that it takes to deploy Contexa is too high, and the effort to tune things is too high, and the upgrades are a pain. So I don't think some of the formal announcements have been done about it, but, a big feature of the road map for the upcoming one or two years is around reducing the amount of efforts needed to deploy and tune a context of implementation, Trying to reduce some of the quite context specific skill set. The context specific knowledge is is absolutely essential, but the context specific skills, hopefully less so, and to make upgrades as seamless as possible between that. So I say that there are a bunch of announcements that will be coming in the coming months, so that is is very much the aim. Actually, as part of that, from a TCO perspective, I think we'll be pushing more towards using OpenSearch rather than Elasticsearch, and effectively reducing the support costs for our customers by doing that. Yeah. Lovely. And I'll do a very shameless plug for the community. We do have a road map, on the community that you can visit, you can explore, you can vote on features that are important to you and your organization, and really make sure you're also involved in that process as well. I I just wanna pick up on the the simplicity point that Chris mentioned. So I I think that's something that I I see with every client in that. Every client has a, their own way of deploying the the solution, their own CICD tooling, own build and development processes. So that actually forms a large part of the project. And as you say, Chris, the simpler we make it as a solution, the easier it will be to drop it into your existing deployment tooling and reduce a lot of that that effort that's always nonfunctional, and it is is harder to explain to your business customers, and make it simpler for the technology teams. Lovely. Thank you very much, Carl. So then our next question is a question we actually had from this morning session. What does a typical context implementation journey look like, and what can we do to set ourselves up for success early on? I can take that. So simple journey, will be your start with an with an idea. Do we need entity resolution? We our data isn't ideal. Would we like we've got a few different sources that may maybe we should be combining together. Maybe we're thinking about anti money laundering. Maybe we're thinking about customer intelligence. And you have a thought of, you know, do we need a solution? At which point, you know, you'll start an engagement with our with our account team and, and you'll have a few demos of of Quantexa. I'll roll it on to when a when a project begins. Of course, I think most of the people on the line will have gone through this, but it's okay. What do we need to deploy a Quantexa solution? Need to understand the the infrastructure in play, the data volumes, the sources that you're that you're interested interested in. And then you'll start to think about, okay, how would we combine these data sources? And you'll start to bring in your subject matter experts in terms of the data. You'll be be involving your your business teams in terms of what outcomes do we need to get to. The outcomes you need to get to are always very important, probably the most important, and it's something that we we like to drive drive up front. You know? Do we are we looking to reduce false positives in money laundering? Are we looking to increase the, your exposure to, new customers? Coming back to the technical side, what do we then look at? We look at how do we deploy the solution. So it's you know, we need some infrastructure. We need spark. We need elastic search. We need other infrastructure components. And then we'll get to the once everything's con everything's available, once all the dependencies are available, once we've decided on the solution, we'll, you know, start to put together a design, put together an architecture, and then we'll on onboard a team and work with with your team on how we, ingest the data and take that from an initial concept through to, having an m MVP. I can probably go on forever, but I'll I'll take a pause and see if anyone wants to add. All good. Lovely. So I guess we kind of got, time time for maybe one or two more questions. If anyone does want to send anyone in, please do. And if not, we can move on. So can you share some examples of customers expanding from one use case into another, and how does the architecture support that? Oh, shit. Do you fancy picking that up? Sure. I, was looking for the unmute button. I that's an interesting question. I think I can essentially just add to what Chris and Carl, mentioned in other, questions about moving from one single use case to another, or making a platform multi use case doesn't necessarily need a huge amount of architecture or design support. The way the context of product, is architected relative to, being just an open architecture platform enables, a quite fast and rapid, enabling of enablement of multi use cases. What what we do, from an architecture point of view is more about the health, the maintenance, and ensuring that, if there is a new line of business requiring a new set of requirements that, results into a new use case or a are able to make the best out of the platform without, you know, too much rearchitecting or redesigning the actual platform that is, deployed and installed, for our customers. A lot of work goes into applying the best practice and principles. Obviously, when you have one single use case, you don't necessarily have the best practice in your priority. But as as it expands, then you do you do appreciate examples, best practices when it comes to deployment. The logs of the CICD, the logs of how the release chain, the the testing cycle can work, addressing different, you know, types of requirements without without, reinventing the wheel, if you will. So it shifts from, designing and solutioning that we do, for the start of of of an implementation or or landing it into a kilometer, into just applying more best practices and principles. And what Chris, and Carl mentioned about the easiness of implementations moving forward as a road map is all about how we make sure, not only we are able to implement and build, a new use case, but we're also able to fast and quicker expand without creating too much dependency on lower environments and how much of it can be repeated in a more configuration, more a UI driven fashion as opposed to building or or or writing. So, in principle, our work from architecture point of view moves from, designing, in a specific into more making sure it is aligned, with the best practice principle and more training on on or guideline guidelines about, how to how to minimize the the, you know, the the the the the creation of technology debt, as we expand into just more multi use case. And, as as you mentioned, Sophie, we have a a, great deal of documentation about the, best practices when it comes to multi use case on community, which I encourage everybody just to look at and understand and learn more about, the multiuse case principle at Contixo. Lovely. Thank you very much. Yeah. Excellent plug for community there. Then we've had a question come in from Matthew. In your experience, how challenging will it be to migrate an existing Elastic installation to OpenSearch? Yeah. So there's a I I can take this. There's a a few components to this. So there's the infrastructure component of moving the infrastructure across, and then there's the client side where it's, embedded inside of context. So from an infrastructure component, of course, you've you've got your list existing Elasticsearch, whether that's deployed, by your own cloud team using the, ECK operator, or whether that's a managed Elasticsearch cluster inside of one of the hyperscalers. Essentially, you'll need to configure the equivalent for OpenSearch. So there's a an equivalent operator available for OpenSearch. As Chris mentioned, we're looking to provide some some simplifications there as well, which will be will be coming soon as in how to deploy OpenSearch. But for now, it's you'll make use of the OpenSearch operator in a very similar manner to how you deploy Elasticsearch. In terms of then, connecting and and loading to OpenSearch instead of Elasticsearch, we have client libraries both for Elastic and OpenSearch. So, essentially, when you within the context or application tier, it's as simple as swapping to the OpenSearch libraries and then, pointing that at your OpenSearch cluster instead. I think that's awesome. Brilliant. Thank you very much. I think that is all of our questions that have come in via chat or, previously posted to community. If anyone does have any very last questions, please do post them now. But, otherwise, just want to say thank you very much for Harsha, Karl, and Chris for joining us and everyone else for joining us as well. As mentioned, we will be sending out a survey. So if you could just spend five minutes filling that in, it will really help us, putting putting on events in the future on webinars. But, otherwise, I hope to see everyone very soon, and enjoy the rest of your days. Thanks you. very much. you.