Founder of Paul Gresham Advisory LLC and Managing Director, Head of Digital Client & Marketing Platforms and Agile COE Lead in a global bank on controlled delivery in regulated environments and why the same principles now apply to AI
A study by the IBM Institute for Business Value, based on a global survey of more than 500 bank CIOs, found that 94% of core banking modernization projects exceed their planned timelines. Fewer than half of the surveyed executives reported substantial improvements in operational efficiency or customer experience. Paul Gresham spent over a decade inside one of the world’s largest financial institutions, assessing the work of professionals during 360° Peer Evaluations, overseeing platforms that supported flows of over CHF 1.5 trillion and more than CHF 700 million in annual revenue. As Managing Director, Head of Digital Client & Marketing Platforms and Agile COE Lead, he built and led a global engineering organization of 450-plus people across 11 countries and created processes which are the precursors of his Continuous Compliance Control Protocol (C3P). This automated delivery controls reduced the time required to ship software changes from months to minutes while maintaining full regulatory traceability. We spoke with Gresham about why most bank modernizations stall, what controlled delivery actually looks like, and how the same logic now extends to AI infrastructure.
Paul, the IBM study paints a stark picture: ninety-four percent of core banking overhauls run over schedule, and most CIOs see little improvement in efficiency afterward. You managed platform modernization at a globally systemically important bank for over a decade. Where does the process typically break down?
The root cause is almost always the same: organizations treat compliance and speed as opposing forces. Most banks still operate under the assumption that stronger controls mean slower releases. So what happens is that every software change passes through a chain of manual approvals, sometimes as many as 15 separate sign-offs, before a single line of code reaches production. Each handoff introduces delay, and each delay increases the chance that the change no longer matches the original business requirement by the time it finally ships. Add to that the sheer complexity of legacy systems, platforms that have been patched and extended for decades, with dependencies that nobody fully maps until something breaks, and you get a situation where modernization turns into an open-ended exercise. The IBM numbers don’t surprise me at all. If 94% of bank modernizations run late, the problem isn’t the technology – it’s how we ship it. And what surprises me is that anyone expects a different outcome without changing the delivery model itself.
Your response to that problem was C3P, an original framework you built to automate compliance checks directly inside engineering workflows. Before C3P existed, how did a change actually move through a regulated bank?
Slowly, painfully, and with a lot of paper. At one organization, before we implemented automated controls, every code change required manual tracking: written justifications, reviews by separate teams, and audit logs assembled by hand. A single deployment could take months to clear all the gates. Risk and compliance departments had legitimate concerns about Sarbanes-Oxley requirements and internal control standards, but the tooling to address those concerns hadn’t evolved since the early 2000s. C3P changed the fundamental approach: it ensures that every piece of code released to production is automatically linked to its original business request, that only tested code can be deployed, and that nobody can alter it after the fact. By embedding validation, tamper-evident logging, and traceable execution directly into the pipeline, we replaced over a dozen manual approvals with a fast, continuous process that was actually easier to audit. Deployment cycles dropped from months to minutes, and confidence in compliance went up, not down.
After a major organizational change, what happened to the methodology that drove adoption of automated controls across internal engineering teams, and how did the fact that an external tech platform called Deja was directly inspired by C3P’s architecture influence its evolution or impact?
Typical mergers and changes that happen in large organizations meant the framework had serious attention internally, but the timing was not right to adopt it fully due to a focus on integration versus development. The framework had attracted serious attention internally, directly shaping the firm’s roadmap for how they plan to manage software changes going forward; the logic of automated traceability and built-in controls became a reference point rather than a one-off experiment. Outside the bank, the methodology has started to influence independent work as well: an external tech platform called Déjà (formerly Wallow) was directly inspired by C3P’s design, which tells me the problem it solves isn’t limited to one institution. I’m also planning to publish a paper on the framework, because these patterns should be available to a wider engineering audience.
In your most recent position in finance, you helped an AML policy-critical platform that had been underperforming and cut run costs by approximately 25% — millions of dollars a year, while improving availability and the user experience. What does it take to stabilize a system that regulators are already watching?
You have to be willing to make an unpopular call. When I took over that platform, the instinct from the business side was to keep pushing new features. I paused new development entirely and redirected the team toward root-cause analysis and foundational repairs. We implemented automated testing, CI/CD pipelines, and in-production resilience checks – none of which had existed before. Core client data was migrated off mainframes and onto Azure-based microservices using a CQRS pattern to restrict legacy dependencies. After that stabilization period, the platform could handle five times the peak load it had struggled with previously, downtime dropped significantly, and operating costs fell by about a quarter. When a regulator is watching, the worst thing you can do is paper over reliability gaps with new functionality. Fixing the engine before repainting the car is less exciting, but it’s the only approach that holds up.
Banking technology leadership and the UK National Lottery seem like an unlikely pair, but early in your career, you co-developed the network deployment software that connected approximately 10,000 lottery terminals across the country in under nine months, ahead of the first televised draw in November 1994, which attracted over 22 million viewers. How did that experience shape your thinking about delivery under pressure?
It taught me early on in my career that some deadlines are truly non-negotiable – you have to build your process around that reality rather than hope someone extends the timeline. With the National Lottery, if the terminal network wasn’t ready on launch day, the entire program would have failed publicly and spectacularly. There was no fallback, no soft launch, no beta period. I co-developed the network design and planning application that translated optimization models into executable deployment plans, coordinating with providers like British Telecom to install and test communication lines and terminals nationwide. That six-to-nine-month window left zero margin for rework. Discipline I absorbed from that project defines exactly what “done” means before you start, validate at every step, never assume the next handoff will catch your mistake, and stayed with me through banking, maritime technology, and everything since.
More recently, you released nv-monitor, an open-source GPU telemetry tool that earned over 200 GitHub stars and was discussed in a LinkedIn post reaching more than 100,000 impressions. What problem does it address, and how does it connect to your advisory practice?
I built nv-monitor while extending C3P principles into AI agent infrastructure, specifically, environments where agentic systems run on GPUs and need to produce trustworthy audit trails. What I discovered was that existing monitoring tools misreport key performance metrics on ARM-based and unified-memory architectures, which means the telemetry underlying your compliance records can be wrong without anyone noticing. nv-monitor delivers accurate, low-overhead GPU telemetry across x86_64 and ARM64 architectures in a single binary with zero runtime dependencies and seven to ten times less CPU usage than standard tools. For any organization deploying AI in a regulated context, accurate telemetry isn’t optional; if your monitoring lies, your audit trail is worthless. My advisory practice, Paul Gresham Advisory LLC, is built around that exact intersection: helping organizations implement audit-grade controls for modern CI/CD pipelines and AI deployment, stabilize critical platforms, and improve delivery predictability. Thirty-eight years across telecom, maritime, securities, and banking have convinced me: specific technologies change, but the need for disciplined, traceable delivery does not.
