Ep956: Where Cloud Meets AI: Redefining the Future of Digital Lending

0:00I have a bit of a confession to make to start us off today. Oh boy. What is it? Well, I have this folder in my email inbox and it's labeled AI Announcements. And honestly, at this point, it's basically a spam folder. It is literally a spam folder. I mean, if I see one more press release from some legacy bank claiming they are, you know, an AI first institution. Just because they added a chat bot to their FAQ page. Yes. Exactly. I might actually scream. It feels like the whole industry is just grounding in these buzzwords, but the actually user experience and the backend operations, they haven't really changed since like 2015. Yeah. It's a classic lipstick on a pixel area. I mean, everyone wants that valuation multiple that comes with being an AI company. Yeah. But nobody actually wants to do the architectural surgery required to truly become one. Right. And that is exactly why I wanted to pull this specific deep dive together for you today. We are looking at a really dense, fascinating interview from the IBSI Fintech Journal. This is the November 2025 issue.

1:00Scripties. It really is. The subject is Harry Putman upon. He's the founder and chairman of INSEA. And what I appreciate so much about his take is that he isn't out here selling a chat bot. No, not at all. He's basically saying that the entire way we think about digital transformation is just fundamentally wrong. It's a very provocative stance, for sure. He argues that we're in this transition phase right now that is much, much messier than people want to admit. He draws a really sharp line between what he calls doing digital, which is the apps in the chatbots we were just venting about exactly doing digital versus being digital. And his definition of being digital is incredibly rigorous. It's not about overlaying technology on top of old workflows. It's about a fundamental behavioral change in the system itself. Yeah. He drops a line early on in the interview that I actually want to use as our anchor for the discussion today. He says a system becomes truly AI driven only when it cannot function without AI. Which is a massive distinction from where we are currently sitting. Huge. Right now, I mean, if the AI server goes down in a major bank, what happens?

2:02The law and officers just roll up their sleeves and go back to Excel or they log into their legacy mainframe. Right. The business just continues. It might be slightly slower, but it continues. He calls this current state agentic AI. These are basically helpers, you know, co-pilots. They retrieve data. They might summarize a 50 page document. They flag a suspicious transaction for review, but they are entirely additive. You can strip them away and the engine still runs. Precisely. If you strip them away, the core ledger, the core decisioning engine, it all still works perfectly fine. Pat Matapan is talking about something else entirely, which he calls embedded intelligence. This is where the AI isn't a helper sitting on the side. It is the engine itself. If the AI stops, lending stops entirely. To get to that point, though, you need way more than just a software update. And he touches on the hardware shift, which honestly, I think gets overlooked a lot in these fintech discussions. We usually just wave our hands and talk about the cloud as this nebulous, magical thing,

3:04but he's pointing toward highly specialized compute. It's a necessary evolution. I mean, general purpose CPUs, which are the chips running the vast majority of bank servers today, they just aren't built for the kind of heavy matrix math required for real-time AI embedding. They're built for traditional logic, not neural processing. Right. Pat Matapan points out that we are moving towards specialized AI chips and completely distinct architectures. You just can't have a system that learns from every single transaction in real time if you're trying to run it on infrastructure that was designed for batch processing in the 1990s. Which brings us nicely to the first major technical pillar of this interview, the small learning model, or SLM. I want to pause here for a second because the hype train right now is all about large language models. Everybody wants an LLM. Everyone wants to plug chat GPT or Lama into their tech stack and call it a day. But Ansea is placing a huge bet on going small. Why are they swimming against the current here? Well, it really comes down to the fundamental difference between generative and predictive

4:06AI, especially in a highly regulated environment like banking. LLMs are probabilistic by design. Meaning they're just guessing the next word. They are designed to guess the next likely word or pixel in a sequence. That is amazing if you want to write a catchy marketing email or summarize a client meeting. But it is absolutely terrible if you're trying to calculate credit risk or determine loan eligibility because LLMs hallucinate. And you really, really cannot have a banking system that decides to get creative and just invent the credit score out of thin air. Right. The regulators would have a field day with that. You need auditability. You need determinism. An SLM, a small learning model, is architecturally very different. It isn't trained on the entire public internet. Which means it doesn't know about, say, 18th century poetry. Exactly. It doesn't need to. It is trained exclusively on the institution's own proprietary data, its specific risk parameters and its historical outcomes. It's a completely closed loop. So it's not trying to know everything in the world.

5:08It's just trying to know this specific bank perfectly. Precisely. And this directly addresses the data governance nightmare that keeps bank executives up at night. One of the biggest blockers for banks adopting public LLMs is the sheer terror of data leakage. Putting PII personally identifiable information into a public model. Yes. With an SLM, that data never leaves the institution's secure perimeter. But the magic isn't just that it's secure. It's that the model is dynamic. Walk me through that, actually. He talks about how every transaction feeds continuous learning. Now, that sounds great on the slide deck, but how does that actually work mechanically? Okay. Think about the traditional feedback loop in lending, a bank issues alone today. Two years later, unfortunately, the borrowed defaults, that default data sits in a database somewhere. Gathering dust. Pretty much. Then maybe, once a quarter or twice a year, a risk analyst runs a massive report, spots a trend, and manually updates the credit policy for the whole bank.

6:09That feedback loop is months, sometimes years long. Right. It's completely retroactive. You're always looking in the rearview mirror. In the SLM model that Pad Manahan describes, that feedback is immediate and highly granular. Let's say a borrower with a very specific financial profile delays a payment by just three days. The SLM catches that right away. Instantly. It detects that signal and effectively asks itself, did I miscalculate the risk weight here? It then automatically adjusts the parameters for the very next application that looks similar to that profile. It's not waiting for a quarterly committee review. It's adapting on the floor. The system is literally evolving its own logic with every single interaction it processes. That is the embedded intelligence he was talking about. The software isn't just mindlessly executing a set of static rules. It's constantly refining them. But this brings me back to the infrastructure problem. Because you cannot run a self-evolving real-time model like that on a 30-year-old mainframe sitting in some basement. No, you absolutely cannot.

7:09And that brings us to what he calls the cloud conundrum. Pad Manahan seems pretty critical of the current hybrid cloud setup that most banks are so proud of. He basically argues that private clouds are just legacy infrastructure with a better marketing budget. It's a harsh assessment, I'll admit, but it's highly accurate. Most banks are frankly terrified of the public cloud. It's purely a security perception issue. So what do they do? They spend millions building private clouds. They own the servers. They build the walls. They control the perimeter. It feels very safe. It feels safe. But the massive trade-off there is isolation. In a private cloud, you are a single tenant. That means you are solely responsible for every single upgrade, every security batch, every new integration. So you completely miss out on the network effects of the broader tech ecosystem. Completely. You're on an island. Pad Manahan is pushing hard for true multi-tenant size. Think about it this way. In a multi-tenant architecture, the software vendor maintains a single, massive, centralized

8:09code base. OK. So when they develop a new security patch or a brilliant new AI optimization, it rolls out to all 50 or 100 banks on the platform simultaneously. Overnight. But hold on a second. If I am a bank CISO, a chief information security officer, the phrase multi-tenant sounds an awful lot like shared data. If I'm sitting on the same infrastructure as my biggest competitor, how do I know for sure my data isn't leading over into their models? That is exactly the trust gap he mentions in the interview. But the reality of modern multi-tenant architectures is that they use incredibly strict logical separation. We're talking database sharding, advanced encryption at rest, encryption in transit. So the data is technically co-mingled on the physical hardware, but mathematically isolated at the software layer? Exactly. So what I'm trying to say is that the security of these massive, solid platforms is actually significantly better than what any single bank could ever build on its own. Because the vendor is amortizing the cost of top to your security across hundreds of

9:13wealthy clients. Right. They can afford the best cybersecurity talent in the world. You might feel safer in your own private bunker, but you're actually way more vulnerable because you just can't afford the same level of sophisticated defense systems that a cloud native giant can. And you definitely cannot afford the speed. That seems to be the real killer here. Private clouds are rigid. If you wanted to deploy that fancy new SLM capability we were just talking about in a private cloud environment, that is a six month integration project minimum easily, whereas in a multi-tenant size, it's just a feature flag. The vendor flips a switch and it gets turned on overnight, which perfectly leads us to the part of the interview that made me, frankly, the most skeptical, the concept of zero implementation. Yeah. It only sounds like a glossy sales pitch, doesn't it? It sounds like pure vaporware. Right. I have been through major enterprise software rollouts. I know what they look like. They are never zero implementation. They are two years of absolute misery, scope creep, and budget overruns. How can unsee a possibly claim zero implementation when they are dealing with highly complex financial

10:17products? Are they just bypassing the core banking system entirely? They aren't bypassing the core, but they are dramatically abstracting the complexity. Ed Manahan makes a very deliberate distinction here between implementation and go live. Okay. What's the difference? He says implementation implies a massive construction project where you were building custom code from scratch, writing new logic, testing it, fixing bugs. Go live, on the other hand, implies configuration. Okay. But configuration in enterprise banking usually means low customization. If I'm a bank and I have a very specific, highly nuanced, tiered interest supply chain finance product with weird bespoke repayment terms, can a no-code platform actually handle that? Or am I just stuck with a generic vanilla template? That is historically the trade-off, yes, customization meant coding. But Ed Manahan argues that they have fundamentally productized the granular logic blocks themselves, not just the user interface. They use a proprietary tool called unsee a studio.

11:17So how does that work? Sort of writing custom code to say, you know, if X happens, calculate interest like Y, you are actually dragging and dropping pre-validated, pre-audited logic modules on a canvas. So the complex financial math is already baked into the block itself. Exactly. The block is a hardened, compliant financial component. You were just assembling them in a specific order. This entirely shifts the workload from the IT department who historically had to code, test, and debug everything over to the business product team. And people who actually understand the business logic and just need to configure the flow. Right. So zero implementation doesn't mean zero work. It means zero coding. Exactly. It completely removes the traditional software development lifecycle from the critical path. You aren't writing code. You are just tuning parameters. And this allows for what he calls the self-serve model. The bank literally does not need to call the vendor to launch a new product. All right. I wanted to see the receipts on this. And he brings up Unity Bank as the concrete proof point. And the numbers here are frankly aggressive.

12:19He claims that they booked 1,000 fours in supply chain finance in just six months. Now for our global listeners, 1,000 cores is roughly 120 million US dollars. For a brand new program launch, that is incredible velocity. It's massive. But honestly, the number that really matters in that case study isn't the monetary volume. It's the timeline. He states that Unity Bank can configure and launch a completely new finance program within 24 hours. Let's rule into that for second 24 hours. Does that actually include UAT like user acceptance testing? Does it include compliance and regulatory checks? How do you compress a standard three-month launch cycle into a single day? This circles right back to those pre-validated blocks we just discussed. If you are coding a product from scratch, you absolutely need weeks of testing to ensure you didn't accidentally break the core math. Right. But if you're using pre-tested certified modules, the UAT phase is significantly faster because you are only testing the arrangement of the blocks, not the internal logic of the components themselves. So the compliance rules and the regulatory guardrails are already embedded in the blocks?

13:23Yes. Exactly. The guardrails are part of the core configuration. So a business user practically cannot accidentally build a non-compliant product. The system won't let them. This is what allows the bank to move from a signed agreement to a full market launch in under a day. That changes the strategic landscape completely. Right. When you launch a product in 24 hours, you can run actual micro experiments in the market. You can test a specific dealer finance program for just one small region, see if it actually works, and then scale it up or kill it without having burned a million dollars in IT setup costs. And that is exactly what Unity Bank did. They leveraged supply chain finance, which, as we know, is a very high-volume, revolving credit product to deepen their relationships with existing corporate clients. Instead of spending millions on new customer acquisition. Exactly. They just monetized their current ecosystem much, much better. And they could only do that because the technology allowed them to customize the financing offer for entirely different supply chains almost instantly.

14:24There's one final piece of this puzzle that we need to hit, and it's the money. Not the money the bank is lending out, but how the bank actually pays for this underlying technology. We are seeing a major shift from CapEx capital expenditure to OPEX operating expenditure. This is the democratization angle of the whole in CF philosophy. Historically, buying a core lending system was like buying a physical office building. You pay tens of millions up front for a perpetual license. And if the software didn't work as promised, or if your business didn't grow, you were just out that money. It was a sunk cost. It was a massive barrier to entry. It basically meant that smaller lenders, NBFCs, or scrappy fintechs, couldn't compete with the Tier 1 banks on technology. And Sia is pushing this pays you grow model. Right. The cost of the software is directly pegged to your actual business performance. So your software bill is tied to your disbursement volume, the number of transactions processed, or the overall size of your loan book. Now that sounds fantastic for the bank, obviously, but it sounds incredibly risky for the vendor.

15:28I mean, if the bank fails to sell loans, the vendor simply doesn't get paid. It does put the onus entirely on the vendor to ensure their system actually works and actively drives business growth. It perfectly aligns the incentives. They win when the bank wins. Exactly. But more importantly, it radically changes the unit economics for the lender. You don't have this massive depreciation anchor sitting on your balance sheet anymore. Your technology cost becomes a variable cost that scales perfectly in line with your actual revenue. It really levels the playing field. A small SME lender can basically access the exact same Ferrari engine that a massive global bank uses because they are only paying for the gas they actually use. That's a great way to put it. Pobano Pond's point is that the real investment for a modern bank shifts entirely. You have to stop investing capital in static software licenses and depreciating servers. You start investing in people who can deeply understand the data and configure the business strategy. So bringing this all together for everyone listening, we have three main shifts happening

16:28here. We have the intelligence layer moving away from bolted on chatbots towards small learning models that are deterministic and don't hallucinate. We have the architectural layer moving from isolated private bunkers to multi-tenant sauce clouds. And finally, we have the agility layer moving away from hard coding toward drag and drop configuration. Those are the three pillars. Absolutely. If you look at them all together, they describe a completely different kind of financial institution than what we have today. It really does make the current industry debate about, you know, will AI replace bankers feel a bit shallow? It seems like the real question we should be asking is, will AI replace the traditional process of banking? That's the right framing. Pat Manophan isn't talking about replacing the human relationship aspect of lending. He's talking about replacing the static, dumb workflow that currently sits between the banker and the customer. He explicitly mentions blending AI with human judgment. Let the machine do the math, let the human do the relationship. Exactly.

17:29The system handles the context to wear intelligence, the heavy mathematical lifting, the historical analysis, the pattern recognition, so the human banker is freed up to handle the nuance and the strategy. But it does require a serious leap of faith from the institution. You have to trust the black box to some degree. If an SLM suddenly changes a risk waiting because of a subtle pattern it saw just yesterday, the human banker has to trust that the system is actually smarter than the manual policy they wrote six months ago. True. And that trust only comes from extreme transparency and auditability, which is exactly why the shift to deterministic SLMs is so critical for this industry. You can audit the internal logic of an SLM. You can prove why it made a decision. Whereas you can't easily audit the logic of a massive neural net that's just guessing probabilities based on the whole internet. No, you can't. For the listeners out there, whether you're working in a traditional bank, a scaling fintech, or you're just keeping an eye on this space, what's the ultimate litmus test here? How do they know if their own organization is actually being digital or if they're just

18:29doing digital? I would tell them to look closely at their feedback loop. That is the single most important metric to evaluate. When your organization makes a decision, whether that's approving alone, rejecting a customer, or setting a new interest rate, how long does it take for the real world outcome of that decision to reprogram your core system? And if the answer is, well, we wait for the quarterly strategy meeting to review the data you're dead in the water. You're obsolete. The ultimate goal is to shrink that feedback loop to near zero. The transaction itself should be the lesson. The transaction is the lesson. I really like that. It moves us fundamentally away from just data storage and towards actual data intelligence. We are definitely entering an era where your competitive advantage isn't just who is hoarding the most data, but whose data actually teaches their system the fastest. It's a fascinating, slightly terrifying, and incredibly exhilarating time to be watching this industry. It really feels like the training wheels are finally coming off. I think the race is genuinely just beginning.

19:31I want to leave you all with a final thought to chew on as we wrap up today. We talked a lot about Pied Manopani's core philosophy that true intelligence and lending will emerge only when every single transaction teaches the system to make the very next decision smarter. It's a very high bar to set. It is. So I want you to look at your own workflow today. Not just your software stack, but your actual daily grind. Is the work you are doing right now actually teaching your system to be better tomorrow? Or are you just feeding a graveyard of data that no one will even look at until the next compliance audit? Because the difference between those two things is a difference between building a legacy and becoming one. I couldn't have said it better myself. Thanks for joining us on this deep dive. We will catch you on the next one.