Spoiler: it isn’t a paperwork problem.
Thirty-five years of building banking software taught me one thing about compliance
The first regulated software system I ever helped ship was built on equipment most readers of this blog have never seen. We had a deployment process, of sorts. Someone wrote a memo. Someone else signed it. The release went out on a Friday because nobody trusted it not to break, and we didn’t trust ourselves to fix it on a Saturday. If you wanted evidence that the change had been authorized, you went down to the filing cabinet, pulled out the memo, and waved it at the auditor.
I am writing this from a desk in Westchester County, New York, in 2026. The world I am about to describe is not that world.
In the intervening thirty-five years I have built and governed software for trading firms in London, brokerages in Hong Kong, a startup in Singapore, and the global wealth divisions of two of the world’s largest banks. The pace has changed almost beyond recognition.
The Singapore startup, since I am here, was called NX2U.com — Next to You — a video-conferencing platform that, in the early 2000s, was a credible rival to Webex. It was canceled when our investor concluded that broadband would never become a mainstream consumer technology. We had determined that the product needed it. The timing of that judgment, looking back, has aged in ways the investor probably did not foresee.
The teams I lead today release software dozens of times a day. The systems I oversee process trades on a notional volume that, in the mid-1990s, would have been the entire output of a small country.
The compliance frameworks, however, have not kept pace. The filing cabinet has been replaced by a Confluence page. The memo has been replaced by a Jira ticket. But the underlying mental model — that someone, after the fact, will assemble proof that the system did what it was meant to do — is essentially the model I worked under in 1991.
This is the thing I have come to believe, after watching the gap between delivery practice and compliance practice widen year after year:
Compliance, as the industry currently practices it, is solving the wrong problem.
What I thought the problem was
For a long time I thought the problem was people. Some auditors were too pedantic. Some engineers were too cavalier. Some senior leaders were too willing to fudge the line between “moving fast” and “skipping the controls.” If you got the right people in the right rooms, things would work.
This is not entirely wrong. People matter. But it is not the explanation.
I then thought the problem was tools. If we just had better issue trackers, better deployment automation, better evidence-collection systems, the friction would go away. We bought the tools. The friction did not go away.
Then I thought the problem was culture. If engineers respected compliance and auditors respected velocity, we’d find an equilibrium. Some organizations got close. None of them found a stable equilibrium.
What I eventually realized — and it took me longer than I would like to admit — is that the problem is architectural. The compliance industry asks “did the right thing happen, and can we prove it after the fact?” Modern software delivery answers a different question: “is the right thing happening, continuously, and can we observe it?” Those are different questions. They produce different systems. And the friction between them is not a personality clash. It is a category error.
The moment it landed
There is a particular meeting I remember, in Hong Kong, around 2021. I was responsible for the technology supporting a major trading and wealth-distribution platform. The platform processed trade flows at a scale where a 0.01% control failure represented more than a hundred and seventy million dollars of real exposure. I was in the room. Audit was in the room. The engineering team lead was dialed in remotely.
The controls were not automated back then; they were being defined. By that point I already had a working software-delivery controls playbook. The technical pieces existed; the question was not whether the controls could be implemented. The question was how to bring the engineering team and the audit team onto a single go-forward strategy that enabled delivery and reduced risk at the same time.
The conversation, at first, was the conversation everyone in this industry has had for decades. Engineers explaining why fifteen signatures did not scale. Auditors explaining why velocity without proof was unacceptable. Both sides waiting for the other to concede.
What changed that day was not who was in the room. It was the question we agreed to ask together. Instead of “how do we make the audit process less slow,” we asked, “what would it look like if the delivery pipeline produced the audit evidence as part of the work itself?”
That is a different problem. And it has a different answer.
We linked every code change to the business decision that authorized it. We recorded every review as part of the pipeline, not as a separate sign-off. We made every deployment carry a verifiable provenance chain all the way back to its origin. What we built proved a chain of custody of the code, end to end. The audit function — initially skeptical, as audit teams always are when the engineering side proposes its own controls — independently reviewed it and formally endorsed it. While the application I am describing was a significant one in its own right, the same methodology was extended across more than a hundred applications in the same technology organization.
The thing the framework changed was not the audit process. The thing it changed was the shape of the conversation. Audit was no longer asking, after the fact, “can you prove what happened?” Engineers were no longer scrambling, six sprints later, to assemble the proof. The proof existed. The pipeline produced it. Some of the old, gnarly systems slowly started to improve. I was no longer bogged down in calls about stability issues and failure to deliver.
What I am working on now
Modern AI techniques can now automate compliance controls in ways that simply were not possible two years ago. For the first time, we can have true continuous compliance — produced by the delivery pipeline itself, in real time, not assembled retrospectively. Today I am building C3P — the Continuous Compliance Control Protocol — a portable, audit-grade control framework that takes the chain-of-custody methodology I described above and makes it available to any regulated organization. C3P is not specific to one bank, one platform, or one toolchain. It defines the control objectives — traceability, integrity, provenance, continuous evidence — that any regulated organization must satisfy, and a minimum artefact graph that any modern delivery pipeline can produce.
A working reference implementation is publicly available at github.com/PGALLC/crisis_monitor. The framework paper is currently under review at a peer-reviewed academic journal, and the framework summary is publicly available at paulgresham.com. I have established a U.S.-based advisory firm, Paul Gresham Advisory LLC, to bring C3P to organizations that want to adopt it.
Since January, through Paul Gresham Advisory LLC, I have also been building out the open-source toolchain that makes C3P-grade controls practical for organizations running AI privately on their own infrastructure. The portfolio — currently five public repositories at github.com/wentbackward — includes Hikyaku (a proxy and load-balancer for AI inference that keeps the messaging layer under your control), nv-monitor (a lightweight Nvidia GPU telemetry tool that has picked up several hundred stars on GitHub), llm-observability (a Prometheus monitoring stack for self-hosted models), resolver (an LLM selection and testing harness for agentic workflows), and remote-claws (a permissioned, sandboxed remote-execution layer for AI desktop agents). The capstone is CRYCO, a fully audited agentic AI runner now in private development — the practical embodiment of C3P applied to AI agents, producing tamper-proof evidence of everything an autonomous agent does.
The arc, when I look at it from a step back, is consistent. Highly regulated, highly manual, high pain — that is where I started. Tighter controls, fully automated, easy to use — that is where the work is heading. The same control objectives. A different architecture for satisfying them.
The first essay in this series, Why your audit team and your DevOps team are both right, takes the engineer-versus-controls tension head on. This blog will, over the coming weeks, work through both halves in plain language: what CI/CD/CC means and why it matters, how to tell whether your organization has a Chain of Custody problem, what continuous compliance looks like in the age of AI coding agents, how to walk through the Crisis Monitor reference implementation step by step, why I am building open-source AI infrastructure on dedicated GPU hardware in my home office, and what CRYCO will look like when it is ready to show.
The one thing
If thirty-five years inside this industry have taught me anything, it is this:
Compliance is not a tax. It is a design constraint. And like every design constraint, the right answer is to build a system that satisfies it as a natural by-product of doing the work — not a separate, parallel, retrospective bureaucracy that resents the work and is resented in return.
Engineers should not have to choose between velocity and assurance. Auditors should not have to choose between scepticism and pragmatism. Regulators should not have to choose between innovation and control.
It took me thirty-five years to phrase that clearly. Now that I have, I am going to spend the next decade making it real.
Paul Gresham is the creator of C3P (Continuous Compliance Control Protocol) and founder of Paul Gresham Advisory LLC. He has spent thirty-five years building and governing software in regulated industries, with senior technology leadership roles at global financial institutions. He writes about continuous compliance, software engineering controls, and AI governance. The Crisis Monitor reference implementation is available at github.com/PGALLC/crisis_monitor.