Building The Future Show - Radio / TV / Podcast

Gresham Technologies plc is a global leader in mission critical software and automation solutions for financial services.

Our award-winning software platform helps firms operate efficiently, manage risk, stay compliant, and focus on their customers knowing that their data and digital processes are under control. We’re proven at nearly three hundred organisations worldwide, including many of the world's largest banks, investment managers and corporates.

https://www.greshamtech.com/

What is Building The Future Show - Radio / TV / Podcast?

AM/FM RADIO/PODCAST & TV SHOW

With millions of listeners a month, Building the Future has quickly become one of the fastest rising nationally syndicated programs. With a focus on interviewing startups, entrepreneurs, investors, CEOs, and more, the show showcases individuals who are realizing their dreams and helping to make our world a better place through technology and innovation.

Intro/Outro:

Welcome to Building the Future, hosted by Kevin Horek. With millions of listeners a month, Building the Future has quickly become one of the fastest rising programs with a focus on interviewing startups, entrepreneurs, investors, CEOs, and more. The radio and TV show airs in 15 markets across the globe, including Silicon Valley. For full showtimes, past episodes, or to sponsor this show, please visit building the future show dot com.

Kevin Horek:

Welcome back to the show. Today, we have Neil Vernon. He's the chief product and innovation officer at Gresham Tech. Neil, welcome to the show.

Neil Vernon:

Thank you, Kevin.

Kevin Horek:

Yeah. I'm excited to have you on the show. I think what you guys are doing at Gresham Tech is actually really innovative and cool, but maybe before we get into all that, let's get to know you a little bit better and start off with where you grew up.

Neil Vernon:

Yeah. And I'm gonna start off with one of my favorite, British American jokes. I know that humor doesn't cross the Atlantic very well, but let let's try it. So, I'm from one of the Hamptons, actually, one of the original Hamptons, a place called Wolverhampton,

Kevin Horek:

which Okay. Very cool.

Neil Vernon:

You don't know Wolverhampton, but I I think Cornwall is one of the least, correct. It's it's at the center or it was at the center of the industrial revolution. So

Kevin Horek:

Yeah. Well, that's cool in itself. No?

Neil Vernon:

It it is cool in itself. Yeah. Yeah. Yeah. No.

Neil Vernon:

I'm very proud of of of of that background and that town, and it's certainly where I where I where I grew up and, you know, I as I say, I'm very proud of it.

Kevin Horek:

Very cool. So you went to university. What did you take in wine?

Neil Vernon:

Yeah. And, actually, let let's go back to Wolverhampton just a little bit. Okay. Sure. Yeah.

Neil Vernon:

So you may you you you're probably older enough to remember Tandy. Yeah. And Tandy, in its first venture across the Atlantic to the UK, actually set up its UK headquarters in Wolverhampton. Oh, interesting. As a gift to every school in the in the in the borough, they gave an old, I think it was called a TRS 80, the you know, one of the original Tandy Computers micro PCs.

Neil Vernon:

They have basic built into it. And I remember this computer arrived when I was about 15 or so, and it sat in the corner of a room, honestly, for about a year with nobody doing anything with it at all. And and one one day, I had a little bit of spare time, and I and I I powered it on and and they provided a manual and and I read the manual and and and I thought this looks a little bit interesting actually. And I and I I did a little bit of programming. It was basic.

Neil Vernon:

Basic in in every sense of the word. But I I became, over the next kind of weeks months, the local the only person in in the in the school, a school of, like, 1600 pupils and 33 100 odd staff, the only person that really knew how to use this computer, and and I started to, you know, use it for various things. I remember, doing some of my physics, my my a level, my the next level qualifications in the in the UK a levels. I remember doing some of my a level work on on that and and, impressing the impressing the teachers, actually impressing myself that I could actually get stuff done on a computer, which actually led to me choosing computing as as my degree subject. So I went to Manchester and did a degree in computing, and and indeed my entire career has been spent, connected with technology and and, and programming in general.

Kevin Horek:

Very cool. I I know it's interesting because I've been in tech a long time, and I'm, like, 40 now. And I started, like, my all the immediate males in my family have been in tech since the seventies. So, like, I had a computer throughout the eighties, and, you know, we were the fur one of the first people to get Internet. And it was just it's interesting because I almost feel bad for people now getting into it because it's so many layers now, and it's so complicated.

Kevin Horek:

And if you don't understand some of the basics, I I find sometimes it can be really, really challenging. Do you agree with that? No. Okay. Interesting.

Kevin Horek:

K. Why?

Neil Vernon:

Because I imagine there was some guy in Tandy in the early 19 eighties that that was saying things like, I remember when I had to solder resistors onto a circuit board and do this and do this. There's so many Interesting. There's so many layers that that that I had to learn, and and and and I feel sorry for for that guy in Wolverhampton that that's having to learn about all of these different things. And I think, you know, we we get to, ultimately, we get to various layers of of of abstraction, and and those layers of abstraction keep it simple for us. So I I don't I I I don't know that I do feel sorry.

Neil Vernon:

I don't I don't think it's I don't think it's I mean, obviously, it's changed a lot. It's changed absolutely enormously. The level the layer of abstraction we're dealing with is so so different now. Sure. Keep going.

Neil Vernon:

Lost. No. Keep going. But, yeah, I I I I don't feel sorry. I I I do I do end up having interesting conversations with my own children where I start to explain things about what's actually going on under the covers with the programming language, and then I realize, you know, do they really need to know this?

Neil Vernon:

They they they don't because the language, the computer is taking, you know, taking account of that level of abstraction, that that level of detail that they they no longer need to know about. So no, I I don't I don't feel sorry. I I I'd love to be starting out again, actually. I think the the, you know, the the power of the modern computer that we're gonna I know we're gonna talk later about AI, the power of AI. I think there's so many I I'd I'd love to be at the the the outset of my career at this point.

Neil Vernon:

I think it's just so so many interesting things happening.

Kevin Horek:

Very cool. Okay. So walk us through your career, and then let's dive into, Grissom Technologies and how you, ended up coming there.

Neil Vernon:

Yeah. Sure. So, I left Manchester and came to London.

Kevin Horek:

Okay.

Neil Vernon:

And I joined the I joined a company called Logica who one one of the leading UK software houses at that time, and they took on largely, big infrastructure projects. And, actually, my my first project, and it's one that I am very proud of, is, I actually worked on the channel tunnel.

Kevin Horek:

Oh, cool.

Neil Vernon:

And and the particular I I was I was seconded to the architects for the tunnel and the the architects that were building the UK end of the of the tunnel at Folkestone. And the particular challenge they had was wanting to know how big to build the car park and how many platforms should they build. And if people spend an hour in the duty free shop versus half an hour, what would that do to the to the the the size of the car park? And if the trains were running late, would the car park overflow, and would it would it spill over into the freeway, into the motorway that runs down to Folkestone? So I I I built for them a simulation in Fortran of the of the channel tunnel and and modeled how the car parks essentially and how the platforms would operate, under various various scenarios.

Neil Vernon:

And, of course, you know, on the one hand, they wanted to build as minimal amount of infrastructure as possible. But on the other hand, they knew that ultimately they might get fined if the car parks were too small and the freeways were all backed up because the people couldn't couldn't park their cars waiting to get onto a train. So it was a really interesting challenge and one that I enjoyed immensely. And it was my first foray. In fact, it's been the only foray in my entire career into the FORTRAN programming language, which which at the time was a really interesting language.

Kevin Horek:

Sure. Yeah. Well and I think it it still can be in demand for certain kinda legacy systems. Right? So people still do use it.

Kevin Horek:

It's rare probably, but I've heard of some people using it still.

Neil Vernon:

I think you said that that would be like COBOL where there's a mythical COBOL program that can earn a in a in a in a day given that it it it's bizarrely still used.

Kevin Horek:

Yeah. There's, like, you know, there's less than a handful of people and there's figures left over.

Neil Vernon:

Yeah. Yeah. Exactly. Fair enough. Let's just move on with my career.

Neil Vernon:

So I I worked on a number of different, actually, all transport related projects. So I I I I did the ticketing, what the I I was a a minor member in a team that did the first electronic ticketing for the London Underground. I did those dot matrix displays that tell you when the next train is going to arrive and works on works on that for the London Underground. But, of course, when you're in London, there's a there's a financial draw to the city of London, and the city of London, as always, is demands technologies. There's a huge, need for technology in the city.

Neil Vernon:

And 2 after 2 years of my career doing transport related stuff, I was persuaded, and I'll be honest, I was persuaded by the money.

Kevin Horek:

What's the reason?

Neil Vernon:

Yeah. I mean, it was interesting work as well, but I was I was persuaded actually to to join Warburg. So, the of the one of the older UK investment banks at the time, so I joined Warburg. And, I got involved in something that's been a problem throughout my whole career, really, which is how does the bank make sure that its reference data, its static data is is correct? And how do they how did how did they build the right infrastructure for their for their reference data?

Neil Vernon:

At the time, I I couldn't spell static data. I had no idea what it was. All I knew was that they that they decided to build a repository of their customers and a repository of the instruments that they were trading, and I helped them build build a database. And that was a 2 year project, which now you wouldn't do. I mean, now there are vendors in the space.

Neil Vernon:

That's a problem that did exist, still exists, but the vendors correctly identified that the way Warburg do things compared to the way that JPMorgan do things compared to the way that Morgan Stanley, compared to the way that Goldman Sachs do. They all do it more or less the same way, and that was an area that was really ripe for more commoditization and has been commoditized. And these days, you you you you'd buy an off off the shelf solution. But at that time, there were no vendors in that space, at least I don't believe there were. And we had to build our own.

Neil Vernon:

We had to roll our own. So we were at a, going back to that earlier point, we were at a low level of abstraction at that point. But I helped Wahlberg build their first reference data system. And then, I moved into an area of the bank around the management of the banks bank accounts with other banks. And many people aren't aware, but banks do actually operate bank accounts with other banks.

Neil Vernon:

So at the time, Warburg Warburg's US dollar account was with Chase Manhattan in New York. And we were we were challenged with a problem around the balance of that account either being too long, too too much in credit, and Chase were offering zero interest as you'd expect. You know, they're not gonna do any bank a favor. So they were offering 0 interest if the bank was if Warburgs were long. But if Warburgs were overdrawn, the interest was somewhat punitive.

Neil Vernon:

So you didn't want to be overdrawn, but you didn't want to keep it too long. And what and what was causing money to go into that into and out of that account were the buys and sells of US instruments that Warburg were doing at the time. So if they if they if they bought a 100 shares at a dollar each, you know, that would be a $100 that would leave the account. So it was going to be overdrawn by a 100. But, conversely, if they were buying if they were selling $200 worth of shares, then it would be $200 long.

Neil Vernon:

And, at that time, they would they were doing a few 100,000, sort of half a 1000000 or so transactions per day. So half a 1000000 movements into and out of that bank account. And our first challenge was just to tell them tomorrow, what will be your balance? Or or actually, at that time, the trading cycle, I think, was t plus 3. So not tomorrow, but in 3 days' time, what do I predict the balance to be given all of the movements that will take place between now and t plus 3 and and enable Warburg to then move money into the account if they were going to be short or if they were going to be long, then to put that money into some kind of depository instrument which was earning interest.

Neil Vernon:

And that was the kind of challenge that we were set at that time. And what it turns out it's quite an interesting challenge because not every single transaction settles. And when it fails to settle, of course, if you've funded that transaction, if you've moved money into an account to fund it or you've moved money out of the account because it's going to be delivering money. If you've done that and the trade doesn't actually happen the way that you think it's gonna happen, your funding calculation is wrong. And we found that very often, our funding calculation was wrong and is causing the bank to lose money either by paying punitive interest or actually lose money because they weren't making the most of the money that they got that was long in the account.

Neil Vernon:

And we put into Warburg, which by then had gone through a a number of acquisitions, which was by then, I think, Swiss Bank. We put into Swiss Bank one of their very first neural networks where we were looking at every transaction that was due to settle, that was being done today or yesterday or the day before that was due to settle over the next 3 days. And with that neural network, make an assessment of whether it's likely to settle given the history of trades that were like that. So a classic example is at that time in the in the in the in the late 19 nineties, Italian bonds had got a terrible record of settlement. And so if Warburg would or Swiss Bank were trading an Italian bond, then the chances of of it actually settling were something like 20% for many of those instruments.

Neil Vernon:

So you could make an assessment if you did enough of them to any fund 20% or other rules that could be injected into the neural network to make sense of that data. We had a highly successful project, which in fact, it was the bank's most successful project that year. And I was actually awarded a Swiss bank holiday at that time to Silicon Valley. So I was I was given a bunch of Swiss bank business cards. I was flown over to San Francisco, and I was told to spend 3 months in the valley looking at various interesting companies that were out there.

Neil Vernon:

So I met with Next, for example. I can't claim that I introduced Java to Swiss Bank, but I was one of the proponents of Java at SWISS given everything I'd learned on that holiday and actually got involved in the web for the very first time and moved from Silicon Valley to Swiss Bank in New York and helped them build their very first website based on the technologies that I learned about on that 3 month holiday. So a really interesting part of my career on, you know, an early foray into neural networks and what we we will call AI these days and a very, very early foray. In fact, I think, I actually requested that the SBC domain domain name was created at that time so that, and I and at that time, I I I was barely familiar with what what that really meant and how domains actually worked. But that that's a a potted history of some of my some of my career in finance.

Kevin Horek:

Very cool. So how did you get to Gresham, and what exactly do you guys do?

Neil Vernon:

Yeah. How did I get to Gresham? So, after that neural network work, I really felt and and the team I was working with felt that there was the possibility to create some kind of product there. It couldn't be the case that the work that we'd done at Swiss Bank was unique to Swiss Bank. And so I left and ultimately formed with a group of colleagues, a a a a startup company called Pace Metrics, to actually productize that work and and and, try to sell it to the other banks.

Neil Vernon:

And, actually, we had we had our successes, but ultimately, the data confounded us that we didn't have as many successes as we liked, and I was persuaded actually to join a company called SmartStream, working in a very, very similar space. SmartStream were focusing on reconciliation. Okay. So reconciliation is this activity of when the traders settled and the money has entered the bank account or has left the bank account, you need to know that the right money is entered or the right money is left. And you compare the entries on your bank statement with with the entries in your general ledger.

Neil Vernon:

And that is challenging partly because of the volume. You know, there can be these days on a big US dollar account. There could be 20,000,000 entries on that per day or more. So the volume in itself is challenging, but also you end up with these one to many relationships. So the bank pays out $100,000,000 but it does that in 10 lots of 10,000,000.

Neil Vernon:

So you've got 100,000,000 on one side and you've got 10 lots of 10,000,000 on the other. Or you end up with these many to many relationships. So so many transactions on one side matching to many transactions on the other. Banks are remarkably good at throwing away important data. You know?

Neil Vernon:

If you if you're matching what you think should be in your bank statement against what your general ledger has, one of the most important things is the reference number. And most banks are really poor at maintaining that reference number through their infrastructure. So SmartStream and other vendors made money from productizing that check, that final check of is all the money I expected to move has it moved? And all of the instruments that I've traded, have they all ended up being traded? Have all of my positions been updated correctly?

Neil Vernon:

It's an important check. It's a regulated check. It has has to happen every single day, and there is an expectation that check every day, and you're measured as a vendor in that space. You're measured on how good your match rates are, and the match rates need to be supremely high. You need to be at the 99.9999.

Neil Vernon:

You need to get to 6 nines of match rate. Otherwise, the manual effort that's involved is huge. Nonetheless, no matter how good you're matching engineers, you will find that there are problems. You will find that things you expected to happen, just like those Italian trades I referred to earlier, things that you expected to happen didn't actually happen, and humans need to get involved and and look at those problems. And towards the end of my tenure at SmartStream, I did a survey of the SmartStream customers, and I was hearing quite unanimously that they were really happy with the the software that we delivered to them, that we were doing the reconciliations well.

Neil Vernon:

Our match rates were acceptable. We were finding problems. We we and highlighting problems to them. But one of the things that was disappointing to them was that the problem had happened on trade date, and they only knew about it on settlement date plus 1. So they do a trade today, Tuesday.

Neil Vernon:

It settles on Thursday, and on Friday, you find out there's a problem. But in reality, that problem occurred much earlier in the life cycle. And cutting a long story short, I'm just I've already lived a long story. Cutting a long story shortish, I felt that that identification of trading problems earlier in the life cycle was a repeatable problem that people would be willing to invest money in solving. Because if you can fix problems on trade date, not 7 day plus one, you lower the cost of fixing.

Neil Vernon:

You lower your operational risk. You lower your reputational risk. And if we built the right product to identify what are essentially data problems early early in the life cycle of a transaction, then that would that would that would there would be a market. And I actually did a pitch to the Gresham board some 13 years ago giving them a story similar to the one I've just given you really, taking them through what happens in trading, where the problems are, why the problems aren't identified on trade date because the the systems to identify the the problems are not good enough and explaining to the Gresham board that if we built the right product, there was a market to be had, a market that now is referred to as data quality, data certainty, data confidence, and a market where we've now gone from 0 customers in 2010 to having 300 customers that use our software Uh-huh. To give them confidence that the data they're operating over is correct or and and where it isn't correct, that they know about it as early as possible in the life cycle of the transaction so that they can get that transaction repaired and back into this straight through processing path as quickly as possible.

Neil Vernon:

Along the way, we have acquired a number of companies to help us deliver parts of the solution. So a lot of what we've ended up doing is around banks connecting to corporates and delivering data to their corporate customers, and we've been involved in that connectivity. And we acquired a Luxembourgish company to to help us do that. We were in our early days dealing with lots and lots of nonstandard data, unusual formats, bespoke formats, formats that were unique to that bank or unique to that bank's geography or unique to their London office or unique to their equity trading. There were we were dealing with very messy, somewhat complex, poorly understood data, And we proved to our customers that we could make sense of that data and give them certainty over that data and understanding over that data.

Neil Vernon:

And they then many of our customers then set us the challenge of understanding their more standard data, understanding their SWIFT messages, for example, understanding their FPML messages, understanding their fixed messages. Does all the data that's in a more standard format also make sense? And we acquired a company to help us parse more standard messages. Acquired a company called c 24, and we incorporated that into our portfolio. And as we've proven that we can understand problems on trade date and t plus 1.

Neil Vernon:

Organizations then have asked us to start to do their reconciliations as well. So the the work that I had done at SmartStream, we've extended our product portfolio to deal with reconciliation as well. So we deal with data quality issues on t and t plus 1 and reconciliation issues on settlement date and settlement date plus 1. And we do the whole gamut now of post trade certainty and post trade understanding of of of of the of the settlement cycle. And part of our industry, as you may be aware, we we split our industry very broadly into the buy side and the sell side.

Neil Vernon:

So the the the the buy side are holding on to instruments for much longer and have, in many ways, a more extensive set of requirements. And to yeah. About 2 years ago, we acquired a US company, Elektra, Elektra Information Systems, who have some specialized technology for the reconciliation of the buy side. And we've been busy over the last 2 years incorporating that into our product portfolio. So 300 customers, many acquired organically, but also many acquired through acquisition.

Neil Vernon:

And we built a portfolio through of capabilities through those acquisitions and organic growth. When I did my pitch to the Gresham board, I said that I would need 12 developers to develop the solution.

Kevin Horek:

Okay.

Neil Vernon:

Somewhat embarrassed to say at this point, we have 80 80 developers working, within development on all aspects of data quality and reconciliation and indeed connectivity, connecting banks to their corporates, connecting banks to their trading venues. So that's that's, in a could say in a nutshell, but a very big nutshell, what what Gresham do.

Kevin Horek:

Okay. Very cool. So how are you leveraging AI in all the technology that you just talked about, and how does it basically help with everything you've talked about so far?

Neil Vernon:

Well, that's a good question, isn't it? How does it help? So we deal we we deal with a lot of complexity. And from the very from our very earliest kind of customers, in fact, customer number 2, we started to develop some degree of AI and machine learning around trying to tame some of that complexity, trying to understand that complexity, trying to, from data alone, understand the business rules because we knew that the when you when you check to see if you got a problem, you're really executing a business rule. Right.

Neil Vernon:

And there are many, many business rules to be built. Many and if you leave that entirely to manual efforts, that that will take you a long time. So we invested in in in those early days in understanding from the data alone what the business rules might be, and that's been very successful for us and and very successful for our customers, less successful for our PS folk because it reduces the amount of effort required to configure our system. But, nonetheless, you know, a a a good piece of AI tech that given the data that the organization is processing produces a rule set of how the of of whether that data is correct or not from the data alone. So a a big leg up in terms of configuring our system.

Neil Vernon:

We are doing a number of proof of concepts now around whether given that something has gone wrong, there are a number of things that have to happen with that data. So it's gone wrong. Who in the organization is responsible for fixing it? And we think and and we're doing proof of concepts that look very promising. But the assignment of a problem, the the assignment of a break to a person or a part of the organization seems to lend itself to to to AI.

Neil Vernon:

Having assigned it to the right group, we've also been looking at whether it makes sense to try and guide the human as to what the root cause might be. What are the what are the paths of investigation? So at the very, very minimum, can we suggest how they should fix this problem? And indeed, we we see this developing into, say, not just propose a fix, but in some cases, we will have sufficient confidence in the AI to to to resolve the issue. We also see that when people are confronted with problems, they often try to make sense of the of the wider data set, and they start to ask queries of that dataset.

Neil Vernon:

So if they've got a problem with an equity swap, they might ask a question of, show me all of the equity swaps that were traded yesterday with this counterparty or in this location that were over a certain value or, were were were with a certain risk profile. So they start to construct quite complex questions to ask of that data. And what we found is that those questions are sufficiently complex that the human sometimes has difficulty constructing the right question, and they refine and refine and refine. And we've done some, again, proof of concept work, but, again, really promising where we get the human to suggest or to ask the question in natural language and give feeding that natural language into a large language model, the a large language model that knows about our data model and can convert a a quite natural language question into a complex, more algebraic expression for our query language. And, again, we're finding success there, and I I look forward to being able to embed that in our product so that people, when they're asking these complicated questions, can ask them in English or French or German.

Neil Vernon:

Can ask them in a natural language rather than having to have a more formulaic way of of of of entering the question.

Kevin Horek:

Interesting.

Neil Vernon:

I've talked a little yeah. I've talked a little bit about the configuration of our software, and the AI has always been there to help with that configuration. We're we're experimenting with ways of, again, configuring our software through natural language. So we have loaded out all our configuration language again into a large language model and we can now start to ask questions of how should I configure Clarity, control, our software? How should I configure control to answer this to deliver me this kind of financial control, to deliver me this kind of check.

Neil Vernon:

And we're finding that, again, with promise that the AI can, through a conversational kind of interface, construct configuration or help a human construct configuration much more quickly than that human can do alone. Even though we've had a degree of AI in the product for quite some time, the addition of that large language model into what we do can significantly simplify the configurist task. So lots and lots of promise with large language models in in in in our software. And again, looking forward to taking lots of proof of concepts of making those into real code. And that that's that'll be our development challenge over the next 12 months to turn what looked to be really promising ideas into executable, repeatable business that that's embedded into our code.

Neil Vernon:

1 there are probably many words of caution here, one of one of which is I think I think this has been quite well documented, and the LLMs don't always get it right. And we see we we sometimes see really bizarre so really bizarre expressions. So you ask a question, and you expect the LLM to be able to easily formulate the right kind of question to to to our product. And it asks completely the wrong question. So there are challenges there.

Neil Vernon:

So when it gets it wrong, how do you even identify that it's got it wrong? And how do you apologize? You know, what what is the what is the back and forth that you have with the user? Because their question was put completely sensible, but the but the LLM failed you know, it hallucinated. It failed to make sense of it and answered a completely different question.

Neil Vernon:

So there are challenges that we face, but I think they're they're they're well known challenges that the all of the industry faces.

Kevin Horek:

Right. But it's it also it sounds like you're building tools to basically help humans and do some of the more some of the more maybe time consuming tasks, maybe some of the more challenging tasks, but you're basically building technology to really help people not necessarily wipe out their job completely. Or or what is your thoughts around kind of the doom and gloom pros and cons of kind of AI?

Neil Vernon:

Well, I I I think, you know, somewhat sadly, it is it is inevitable that we will save a significant amount of time in the back office. And, indeed, with some automated resolutions, you could you could imagine that some elements of a job and and and possibly a person's entire role could be could be automated way. So I I am part of that doom and gloom in terms of the future of jobs. I'd also observe, and I think we've seen this happen already with RPA, with with with robots, that the knowledge of an organization, the knowledge of why something is done, is it danger of being lost? And the AI is all well and good, but it no longer there's no longer an explanation as to why things happen the way they should happen, and I do have a fear that, we're making our organizations quite brittle.

Neil Vernon:

It's the humans in the organization that are malleable and the humans that can react to when something completely different happens, it's the humans that can understand that well and figure out at at least observe that it's very different and start start the process of understanding what why is this so different. And I worry, and I've seen I've seen RPAs just break and make an organization resistant to change. And if there's one thing that, certainly, the city of London has been really successful at is innovation, is actually delivering change that has had, I think, enormous benefits for society in terms of the wealth that we've created in the city and in finance that ultimately is good for the for the UK and the and the global population. And that innovation requires that malleability. It requires the organization to be able to respond to change quickly, efficiently, effectively, and to manage the risk of that change very, very well.

Neil Vernon:

And I've got a doom and gloom about AI removing jobs, but I've also got a doom and gloom about when the AI can't respond to change but there are no humans left, Do we become brittle? Do we become less innovative? Do we start to fear innovation? And it's that innovation that's really important to all of us ultimately. We want innovation.

Neil Vernon:

We want it to be controlled. We want the risk to be managed around that innovation, but we do want innovation. And and so just a little bit of a fear there, a bit of doom and gloom there, Kevin.

Kevin Horek:

Interesting. So I I guess, what are your thoughts and advice for actually building some of these technologies into the financial sector? Because, well, banks traditionally aren't known to be kind of the most, innovative in technology, but I think a lot of the stuff that you've talked about today, they basically have to adapt because or adopt, sorry, because it it just it makes sense. Right? Like, it saves them a ton of time.

Kevin Horek:

It can catch a lot of errors. It just speeds everything up. Right? And especially as things just, like, we're so well connected now.

Neil Vernon:

I suppose the the positive there is and I I do agree actually that that that they can be particularly in the back office, the banks can be quite laggards, some may behind where, organization where you expect people to be. So for example, there isn't a single one of our customers that doesn't move files around. You know, they they should be taking advantage of modern messaging solutions like Kafka and queues, but they don't. They move files. So the so you're absolutely in in the middle and back office.

Neil Vernon:

Nonetheless, I have to say out there, there's not a single RFP that we receive. There's not a single sales meeting that I'm involved with that doesn't have AI and ML as a as a as an important part of that sales process, as an important part of their RFP. So I I have to say that that that it's it's not it's definitely not being ignored. I slightly worry on this aspect that it that it it may be seen as a silver bullet. Banks have built up a lot of complexity where they didn't need it or where if you were starting from greenfield, you wouldn't have that complexity there.

Neil Vernon:

And I think it's it's seemed to be, to some degree, a silver bullet to all of the problems that that complex is delivering, and I'm I'm I'm not sure it's there. And I I I I know that, you know, what we're doing and what what other organizations are doing, they have there there have been there are successes to be had. I mean, undoubtedly, lots and lots of successes to be had, but it is not the universal panacea. There are other things that organizations need to do to simplify their infrastructure.

Kevin Horek:

Yeah. And I guess you could use AI to help with some of that, but replace it all. Yeah. To your point, like, you need human beings around if something goes totally sideways or changes.

Neil Vernon:

Yeah. That's what yeah. I think it's you know, it's it it goes sideways because errors just happen, but it goes sideways because the business needs change, the the front office trading strategies change. What they need to do to deliver to the top line requires a difference in in in in processing. And if you're not if you haven't got humans in that mix, that difference is going to cause you enormous problems.

Kevin Horek:

Yeah. That's actually really good advice. So you you've mentioned you've acquired a bunch of companies. Obviously, you've been innovating inside of Grisham for a long time now. What advice do you give to people that are, you know, maybe building startups or thinking about building startups in, the Fintech, kind of banking space?

Neil Vernon:

My number one advice for any start up, I think, actually, is is really work hard. And I think it is hard work, actually, to keep your focus, and it's really easy to chase the next dollar and and and and lose your focus. And just so my strong advice would be know what you do well. Focus on what you do well. Deliver that before you allow yourself to get pulled off in other directions.

Neil Vernon:

It's far too easy to to to chase the dollar and get move away from your focus point, And and that that that that can it will inevitably ultimately mean that you dilute the value that you expect it to deliver. So keep your focus. Absolutely keep your focus. Second thing, I know you asked for one thing maybe. But second thing I have to do is actually I think it's really, really important.

Neil Vernon:

You need to have conversations with your customers. You need to be talking to your customers. You really need to understand what they're saying. And and, you know, sometimes those are gonna be painful conversations because they're not gonna like you know, gonna be giving you a bit of a kick up the backside. At other times, they'll be annoying because you'll be thinking, know, they're asking for that blue button to be green or that green button to be turquoise, and you're thinking, why am why am I spending time hearing such minor minor detail?

Neil Vernon:

I want the next transformative thing. But unless you have unless you have those conversations, you won't you won't hear the transformative thing. So get involved with your customers. Be talking to your customers. Be listening, be understanding what their problems are because that's where you'll hear about the next big thing.

Neil Vernon:

That's where you'll hear. Ultimately, you're gonna be looking for that that common problem, that ubiquitous problem, that problem that's got some degree of urgency, that problem that customers are going to be willing to spend money to deliver. And if you can if you can catch all 3 of those in those conversations with those customers, then you're gonna I think you're on the on the road to being successful as long as you keep that focus. So that'd be my number 1 and number 2. Keep your focus.

Neil Vernon:

Talk to your customers. Talk to your prospects. Never stop talking to them.

Kevin Horek:

No. I I think that's really good advice. But then how do you manage your internal road map or focus compared to maybe some of those feature requests? Because that can be challenging in itself.

Neil Vernon:

The the innovator's dilemma. That's right. You know? Yeah. And it is, and there's there's no easy answer.

Neil Vernon:

So you you've got to be looking for tomorrow whilst keeping the lights on today, and you've got to do you've absolutely got to do both of of those activities. One one of the things I I would encourage is that you do do do try to be a smaller company as possible. Try to keep your processes as minimal as as possible. Of course, the more successful you get, the more likely you are to inject processes in. But you need to be agile.

Neil Vernon:

You need to be agile for delivering to tomorrow. You you need to be somewhat agile for to deliver for today. And it's really important that you keep an eye on those processes. Don't let them get too heavyweight. Don't let them slow you down because the bigger you get, the more people you have in your organization, the easier it will be to become process heavy and you take your eye off tomorrow and actually you fail to deliver for today as well.

Neil Vernon:

So you're failing on both those aspects. It's really easy to do. Just be careful not to do it. Keep yourself lean and agile. Do have some percentage of your budget focused on tomorrow, but keep your customers happy today as well.

Neil Vernon:

Not rocket science, I'm afraid.

Kevin Horek:

Fair enough. I I think that's actually really good advice, but we're kinda coming to the end of the show. So how about we close with mentioning where people can get more information about Grisham Tech and any other links you wanna mention?

Neil Vernon:

The website, www.greshamtech.com. You can find me on LinkedIn. You can find Gresham Tech on LinkedIn. Find out you know, find all of the senior team on LinkedIn. And, of course, listen listening to these podcasts, hopefully, you pick up more information about Gresham as well.

Kevin Horek:

Perfect, Neil. Well, I really appreciate you taking the time out of your day to be on the show, and I look forward to keeping in touch with you and have a good rest of your day.

Neil Vernon:

Kevin, thank you. It's been delightful. Thank you for inviting me.

Kevin Horek:

Thank you. K. Bye.

Intro/Outro:

Thanks for listening. Please visit our website at building the future show dot com to join the free community. Sign up for our newsletter or to sponsor the show. The music is done by Electric Mantra. You can check him out at electricmantra.com and keep building the future.