Building a Lean AI Native Banking Platform With myTU

[00:00:00] Scale your business with agentic AI, with limited risk. With Denodo's AI Data Layer, your agents are provided with real-time company data and guardrails for company protection. Create the business you always dreamed of with Denodo, and you can do that by simply visiting denodo.com to learn more. But now, back to my guest.

[00:00:24] Does a regulated banking platform really need hundreds of microservices and a small army of engineers to remain reliable? Well, my guest today is the co-founder and CTO of My2. I'm going to talk about a very different infrastructure philosophy today.

[00:00:44] After two decades building transactional systems, my guest concluded that infrastructure often receives the blame for the problems created in the application layer. And anyone that has worked inside a large enterprise may have seen this argument within their tech teams, where each leader of the team ends up pointing to each other like the Spider-Man meme.

[00:01:06] But his response was to build My2 around mature cloud services, a compact monolith and one very lean engineering team. What happened? Well, today we're going to discuss why company structure and software architecture tend to mirror each other, how AI supports onboarding and internal decisions, and why evidence trails matter every bit as much as the speed in regulated work.

[00:01:34] And he'll also offer a warning that every builder will recognize. Shortcuts? Yeah, they have a habit of waiting quietly before returning to bite you further on down the line. Lots of big takeaways in this one. So enough from me. Let me introduce you to my guest. Can you tell everyone listening a little about who you are and what you do? Hi, Neil. Hi, everyone.

[00:01:57] So I am CTO and co-founder of Digital Banking Platform My2. It's a brand name. But in the heart, I'm basically, I'm the builder. I'm the engineer. I just enjoy building things. I enjoy being building systems and software and even ordinary things. So it's more than just, you know, IT and technological thing. Love it. Well, it's a pleasure to have you join me today.

[00:02:27] And before you did come on, I was reading a little about you and everything that you do. And I quickly learned you spent over two decades building banking infrastructure. So I've got to ask, what did that experience teach you that you had to maybe rebuild for a cloud first bank rather than simply digitized bank? I feel there's got to be a story there on what made you or what you learned from that.

[00:02:50] Yeah. So the thing is that two decades is definitely banking platforms, maybe not exactly the banking core as itself, because I have been building, acquiring solutions, post-terminal management software, which managed hundreds of thousands of post-terminals, key changes in security, transactional things, that kind of thing.

[00:03:13] So I was building transactional infrastructure. I knew how to build big things that should work 24-7. You cannot stop ever. And most of that, those decades ago was built in house on the in house infrastructure itself. Basically, you have system administrator, server room, another backup server room.

[00:03:35] And that was kind of a struggle a little bit because the infrastructure is always not lagging. Infrastructure was being blamed quite a lot. Because of that, I kind of already kind of acknowledge that infrastructure is not the problem, actually, in many cases. It's the application layer is the bad one, which is usually making poor use of the existing infrastructure.

[00:04:02] You have to adapt to whatever there is for you. You cannot just demand unlimited resources and believe everyone that, oh, my storage is not fast enough or something like that. Another thing is that I also knew that managing extra department, extra set of people for your own infrastructure and for your own reliability things, it's just more sleepless nights when you are afraid that something will stop, that your generator will not work or something like that will happen.

[00:04:29] And therefore, cloud was kind of like solution to everything here because you don't have to argue with anyone. It's very mature service. It's super reliable. If you just use, you know, the basics, the core things of the cloud, if you don't go into the sort of unique advanced things, it will be super reliable.

[00:04:50] And maybe like to sum it up, everything that the lesson here is that, in my opinion, infrastructure is always blamed. But it's just fault. So that's what I learned in those many, many years building systems and watching other systems build, watching over things. And the infrastructure is actually the easy part. You have to do correct application on top of infrastructure.

[00:05:21] And of course, fast forward to present day, the phrase AI native bank is becoming more and more common. So what does it mean inside my two's day to day operation? We hear a lot of noise around AI. So tell me more about the role of AI and which decisions should still remain with humans, of course, too. With AI native, for us, for my two, it means that AI is literally in a lot of different processes on very different scale and levels.

[00:05:48] And I don't mean the support, for example, because everyone was rushing to improve their support using AI systems and so on. This is not our case. This is the last line that is actually getting any assistance from AI in our infrastructure. We build it differently. We build that small things like validating even field input values, converting data, reading data, which is not really well structured.

[00:06:14] AI was there already like one-shoters to just parse something, extract information, extract knowledge, and we build loops on top of everything. And now we have multiple different kinds of agents which handle different processes. Basically, any process, well, process means that there is input of information, somebody takes some actions, and then there is result. So any process, almost any process in digital banking probably can be automated using AI.

[00:06:41] And in my two, it means that we actually do have those fully automatic flows or at least AI assistant flows. Meaning that if a person is doing some job, he has his AI assistant right there in our own back office. On every task, on every ticket, there is an AI that can do analysis, make a summary, extract data, suggest decisions, and then person makes a decision.

[00:07:05] And it moves forward with a very good trace of evidence because even when humans are making decisions now, trace of evidence why it was done is way better quality because AI assisted to collect that trace and just put everything in place for audit for the future.

[00:07:21] And a question I'd love to ask you on behalf of other people listening in heavy regulated industries there is, how have you designed the platform to handle growing transaction volumes while also maintaining resilience, regulatory controls, and customer trust all within a lean team? Actually, it's not that hard once you think how it happened and how it works. There are several things to consider here.

[00:07:49] And I think we'll get back to that again because that's another thing I learned over many years in the software engineering and everything that organizations basically mimic your software that you build or the other way around. If you say you're building software, microservices, lots of distributed things and so on, so is your organization is probably distributed across everything.

[00:08:11] So at the very beginning, we decided to have sort of unfair advantage versus everyone else to stay lean and mean and super efficient. To not burn cash, to not burn time on things we don't want to burn time on. And therefore, our infrastructure and our system that we built was basically already decided there because we will not have a lot of people,

[00:08:39] meaning that we don't need teams of builders, right? There will be a single team, single core building team, which will handle everything in-house development related. And this means that the architecture is the most convenient way is a monolith. You are not building microservices. You're not building a lot of different independent services because there is no benefit here at all. In the end, the application, let's say the big picture application is still the same application. It needs to do everything.

[00:09:09] And microservices is the same monolith, just splits over the network, meaning that any communication, any service restart or disruptions will have an effect. However, if you build monolith, it's way, way more efficient in terms of resources and how everything is being accessed. And then inconsistency once you develop it, because you're developing a single piece of software. And once you upgrade it, everything is upgraded.

[00:09:38] There are no, you know, like some leftovers which are remaining there, zombies or something like that. And everything is just correct and in sync constantly with every single iteration that you build. And that's how we did it. So we basically created a reliable, compact monolith to operate our operations on top of infrastructure, which is reliable, cloud-based, super simple. And it works. I love it.

[00:10:04] And I was also reading that you are applying AI to business onboarding and know your business checks too. So where are you seeing an agent removing genuine friction and where could maybe black box automation create unacceptable risk? Tell me about your experiences there. The thing with black box, probably I'll start with that. The black box is when you actually buy third-party service. I would say that is a black box because you really don't know anything.

[00:10:32] The third party will be providing you some final result. How it works, you might understand a little bit based on what they give to you. But you do not really know if it's true or not, or if it's operating exactly that way or not. You just get results. You get some feedback from clients. You do your own test, obviously, and you find something. But in my opinion, if you have AI system on your own, in-house, it's never black box because it leaves huge trail of evidence on everything it does.

[00:11:03] Obviously, you have to make it leave a trail because if you're not doing that, you have no visibility on how it operates. You cannot improve on its own mistakes in the future. But it's actually not a black box. And the benefits here are enormous because AI is knowledgeable of the world in itself. You can give it intent. You can give it goals, so to speak. I'm speaking about AI like a human. Obviously, it's not human.

[00:11:32] It's not individual. But it's a loop, for example, which at the moment works in such an interesting way that you can actually give intents there. And if you give intents to do key way B, you explain your position, you explain your risk appetite and everything. And you are not over-instructing it. It operates beautifully because it understands the environment. It understands what client already has provided. And it can give client correct questions. Very precise questions. Not just questions.

[00:11:59] Just give me some random document from tax authorities or something. It can ask exactly the correct thing with names, numbers, where to get it, and so on. Obviously, non-deterministic system means that every run is not exactly the same. Because even the same company could onboard and receive a little bit different experience. Because other questions will be asked. Maybe some questions will not be asked. Maybe this time AI will do its own research and will find things it will want to dig deeper. Maybe not. It's non-deterministic.

[00:12:28] I think that's a risk that things might not exactly be the same. But the general checklist that it fulfills is way better than deterministic box, so to speak, that collects information. Because it validates consistency of information. It can extract bits of information from correlated documents and fill everything. And the experience is great. Obviously, the biggest risk here with such system is that because it's running on fully autonomous loop,

[00:12:58] bad actors can try to exploit it. They can try to do prompt injections, send links with instructions, have URLs and their websites with instructions for AI. For example, upload documents with instructions or something like that. So obviously, there are a lot of attempts to do something like that in the industry in general. I'm not speaking just about us, but you just have to harden everything. All the inputs, all the outputs, and then detection of those things.

[00:13:28] And just block those processes, remove the data, collect the logs, collect the experience, improve the cycle next time. With every such attempt, we're just getting more experience and can harden our gates, so to speak. Because there is primary loop and there are gatekeepers who are actually protecting input and output information. And for people using it, where have you seen the biggest frictions being reduced?

[00:13:56] And where does it seem to work best? Oh, the biggest friction is actually a delay. That's a super good question. Very, very good question. Our observation is this, that if you can respond to client immediately, he will fall through to the next question and again and again, and he will just complete the whole process. If you delay the question by 15 minutes or an hour or a day, you will lose client more than you don't. And this is the biggest problem.

[00:14:25] The friction is that clients want everything right now, at this moment. So AI is the best tool to do this because it extracts, it sees that the document is missing something or the document is not good enough. And it asks the next question and the user can provide it. And this is the biggest, probably, impact. And another thing that stands out about what you guys are doing here is My2 owns much of its core technology and also offers capabilities to your partners too.

[00:14:54] So what advantages does owning the stack provide and what engineering burden might come with that choice too? I think you really stand out in what you're doing here. It'd be great to hear how you're managing it, the pros, the cons, again, for other people listening. So owning things, it is advantages because you are independent. So you do not depend on third-party service, its availability, its quality, their capacity to change it, modify.

[00:15:21] Even adding language could be slow on some infrastructures. And some developers, developer teams are just not ready to do some things quickly. So if you own it, you are independent. That's a huge bonus. Another thing, if you own it and you are building it yourself, that means that you can adapt whenever you want, actually. And you can prioritize and quickly change your attention during the day.

[00:15:48] When, for example, something comes up, something important comes up and you can do this the same day, test it and even deliver it the same day. And this is the biggest advantage. The biggest challenge that comes with it, it's not related to ownership itself.

[00:16:08] But because we were building the way we were building, like a lean, monolith infrastructure, not a lot of people, just few developers and everything is very fast. Decisions are made quickly. By the way, similar things, similar friction. Decisions and development process need to be made quickly. The quicker we made, the better.

[00:16:30] So the challenge became like finding good enough talent to work in such environment because you are working way more than in a big organization. You have to keep a lot more things in your memories than in bigger organization. And you're responsible for way, way more. So finding great talents was the biggest, actually, challenge. It's not even an engineering challenge itself. It's just a challenge to find people to do this kind of work.

[00:16:59] And if we have an infrastructure leader who is listening and don't have the luxury of being able to replace that entire legacy banking stack, what is the first architectural change that would produce a real measurable improvement? That's a question which I probably will not be able to honestly answer because it always depends on the organization, which what is your biggest problem. And so on.

[00:17:29] But there is no unique one universal thing which will help everyone. That's for sure. But the bigger bad news is that, like I said, your software mimics your organization or the other way around. Your organization mimics your software that you have. And that means that no matter what you will change in the software, it will always get back to the same state if you do not change your organization.

[00:17:55] Organizational things will not change if your software remains the same. So you have to change two different, totally unrelated things, so to speak, if you think about software and then organization, how they're related. Apparently they are because it's how it is done.

[00:18:11] And the bigger the organization, the more difficult it is because when you, let's say, do something in a different way, newer stack, different tool sets, that's already a problem because you have a lot of other people who are unfamiliar with this and other teams working in completely different way. This creates new teams and new communication between teams. And the same problem delays on decisions. So unfortunately, there is no magic pill here.

[00:18:41] You just have to find your weak spots. And in many cases, weak spot will not be directly in the software. It will be in organizational structure. I would advise probably if the problem is actually a real problem and it hurts your business, start over. Meaning it's not that hard to build nowadays.

[00:19:00] Just take the best people, take the smartest engineers and make it work in a way that you will have a separate organization, which will be designed the same as the software. If you're planning to design software in several, let's say, domains and have several cores running, serving things. As you can see, I'm a little bit of a fan of monolith style rather than microservices style.

[00:19:31] If you're building that way, you organize your organization that way and you make sure it's solid and it never changes. It is not affected by organizational restructuring because every time you restructure organization, the software is affected. I saw this in the big companies and just start over is probably the easiest way to get the results you want and probably the fastest. And you've been on an incredible journey yourself here.

[00:19:58] And I'm curious, if you look back at everything that you've done here, what has building a regulated bank taught you about the difference between moving quickly and taking shortcuts, especially when customers expect both convenience and protection from you, because it feels like you're in quite a unique position here. And I'd love to hear what you've learned from that. Shortcuts bite, literally bite. If you take a shortcut, you're definitely going to forget about it, that you had it.

[00:20:24] And sometime later, maybe in a month, maybe in a year, maybe even in three years, something will come up. And you will find yourself that you were not ready for that situation because you took a shortcut. And now you don't have evidence, maybe or trail of data to recover or restore things. So taking shortcuts is actually not a good idea. If you need to move quickly, that's fine. But shortcuts are very dangerous.

[00:20:48] The only way to take a shortcut is if you want to try a service, if it has any grounds for anything, for a business, for existence, so to speak. Then you take a shortcut here and there, you try this, and then you have to redo the service again. You literally have to rebuild the thing you built before. And because shortcuts are not forgiving you anything.

[00:21:13] And when banks introduce AI into their onboarding and into their operations, what kind of evidence do you think both regulators and indeed their customers should be able to see right from the outset before they're asked to test the result? Yeah, you know, what I'm feeling here in those talks, because there are a lot of discussions in this industry and in other industries, that AI is doing things on behalf of people, making decisions and so on.

[00:21:41] And this is not reliable or not traceable or black box and not visible. How I see it, that it's not really that. I see that AI and people, it's the same thing in terms of evidence collection and regulation and visibility. Because a regulator is not coming to see how your employee is working on their monitor or clicking buttons and everything.

[00:22:06] The audit is happening on the evidence that you already collected, on the traces of everything, of communication, traces of decision-making, notes that employees leave and so on. And it's no way different in how AI operates. You build it to do the same, to do the traces, to make a decision with supporting evidence, supporting notes and so on.

[00:22:30] And from outsider, if you just come to see, the AI one will just look even better because it will have more things. It's more attentive to details than humans are. On the big picture, it might miss some things. But on the attention to details, it's just you cannot compete with AI here. Therefore, I think there is no need for any specific evidence at all from regulators or from people here.

[00:23:00] I just think that the industry itself will just like... If it works, if you build it correctly, it will work. People will use it and audits will go through and everything will be fine. So time will tell, so to speak, that you did it correctly. If you make a mistake, if you build incorrect AI that just approves everything and makes no traces, no attention to detail,

[00:23:26] this will be exposed quite quickly either by clients or by regulators or the audits, internal, outside the audit, anything. So I think in terms of evidence, nothing new is needed here because it's the same people and AI do the same paperwork, so to speak. And time will tell. And I think that is a powerful moment to end on.

[00:23:52] And for anybody listening that would like to find out more information about anything we talked about today, where should they go? Where would you like me to point everyone? I would point probably to LinkedIn because we're posting directly material there or we are posting interviews in terms of podcasts. So LinkedIn is the best. Awesome. I will add links to absolutely everything, including your own personal LinkedIn as well. It would be great for people to contact you and continue this conversation. And so many big talking points there.

[00:24:21] But just thank you for joining me today. Really appreciate your time. Thank you, Neil. Thank you, Neil. I think my guest left us with a refreshingly direct infrastructure lesson. Reliability does not come from adding services, teams or fashionable architecture and the shiny next big thing. It comes from designing the application and the organisation to work together. Choosing mature components and preserving evidence before anybody needs it.

[00:24:50] And I think his case for a monolith will certainly provoke debate. But the wider argument is much harder to dismiss here. Complexity carries operational and organisational costs. AI can reduce onboarding delays, assemble supporting information and help people make decisions. Provided that is that every action is visible and protected against manipulation.

[00:25:17] So a big thank you to my guests for a conversation that moved from server rooms and cloud platforms to audits, architecture and very real warnings about the dangers of taking shortcuts. So if your software mirrors your organisation, what is your current architecture revealing about the way your company really works? Let me know. TechTalksNetwork.com. I'd love to hear from you. Love to hear your stories. If you want to come on here again, let me know.

[00:25:46] But that is it for today. So hopefully I'll get to see you all over at TechTalksNetwork.com. Other than that, I'll be back again real soon with another guest. Bye for now.