post of AI deployment issues as senior banking executive in GRC space, how we overcame them going beyond POC’s real issues and solutions, humor, engagement and end with @laksh Vaswani, so it will come up as hyperlink on linkedin
When the AI Worked Fine. We Were the Problem. There is a version of the AI-in-banking story that gets told at conferences. The version with the elegant architecture diagram, the impressive accuracy metrics, the CTO on stage explaining how they transformed their compliance operations in eighteen months. Applause. Networking drinks. Everyone flies home feeling slightly inadequate. Then there is the version I lived. In 2022, I was part of a team running AI pilots across GRC functions inside a large bank. Six pilots. Reasonable budget. Good vendor relationships. Genuine executive appetite — the rare kind where people actually showed up to the steering committee rather than sending a delegate to take notes. By every measure that matters before you start, we had the conditions for success. Every single pilot stalled at the same wall. — The Wall Nobody Puts in the Business Case The wall was not the technology. I want to be clear about that, because the easy narrative — the one that protects everyone’s prior decisions — is to blame the vendor, blame the model, blame AI for not being ready. That narrative is comfortable and wrong. The wall was our data. Specifically, the state of it. Which is to say: the state of twenty years of accumulated decisions, mergers, system migrations, and the quiet institutional habit of solving urgent problems without fixing underlying ones. Here is the moment I remember most clearly. We had a transaction monitoring model that was genuinely impressive in the sandbox. Clean inputs, clean outputs, the kind of performance that makes a proof-of-concept presentation feel like a TED talk. We moved it toward live deployment and ran the first serious data profiling exercise against our actual production environment. Our data taxonomy contained seventeen different definitions of “beneficial owner” across legacy systems. Seventeen. The model was not confused. The model was doing exactly what models do — processing the inputs it received according to the logic it had learned. We were confused. We had built seventeen slightly different answers to the same regulatory question, across different systems, over different years, and we had simply never needed to look at them all in the same room before. AI did not create that problem. It just turned on the lights. I spent approximately forty-eight hours after that discovery in a state that I can only describe as professionally humbling. I had been in regulated financial services long enough to know that data quality was important. I had said the words “data governance” in enough board papers to have strong opinions about font size. And yet here I was, learning that my organisation did not have a consistent answer to a question that regulators had been asking for years. The AI pilot did not fail. It diagnosed. — What the POC Was Actually Testing The proof-of-concept works because you give it clean, curated data. That is not a criticism of how pilots are designed — it is simply what they are. You select a representative sample, you prepare it, you load it, and you measure performance against a problem you have defined carefully. The POC answers the question: can this technology do what we hope, given the right conditions? That is a useful question. It is not the question that matters. The question that matters is: what are the actual conditions inside this organisation? And the answer to that question, in most large banks I have worked with or alongside, is some variation of: complicated, undocumented, and older than the team currently responsible for it. The gap between sandbox and production is not a technical gap. It is a data archaeology gap. This is the insight that took me too long to reach, and I say that as someone who had read enough about data quality to have formed opinions about it. Knowing that data quality matters is not the same as knowing what it looks like when your specific data estate is the problem. Those are different kinds of knowing, and only one of them is available before you start the work. — Why Transformation Announcements Age Badly There is a related pattern I have observed across organisations — and I wrote about something adjacent to this when reflecting on regulatory conversations in Toronto around crypto adoption, where the same dynamic appears in a different form: the gap between announcing transformation and executing it tends to open exactly at the point where unglamorous remediation work needs to happen and nobody wants to own it. AI deployment in regulated banking is not primarily a technology programme. It is a data remediation programme with a model at the end of it. The model is, in some ways, the reward for doing the hard work — not the hard work itself. The six months of data taxonomy reconciliation, legacy system mapping, beneficial ownership standardisation, and governance framework alignment that has to precede meaningful AI deployment: that work does not make it into the press release. It does not generate a conference talk. It does not produce a metric that looks good in a board update. It produces the conditions under which the actual work becomes possible. Senior leaders who understand this — and I have met perhaps a handful who genuinely do — structure their AI programmes accordingly. They do not budget for a pilot and a deployment. They budget for a data programme, a remediation phase, a governance layer, and then, eventually, a model. The timeline feels slower. It also actually works. The connection to cyber risk is worth naming too: as I explored in a previous piece on the human side of cyber risk, the most dangerous vulnerabilities in complex organisations are rarely the ones the technology missed. They are the ones the organisation had quietly decided not to look at. Data debt in AI deployment has the same character. — What This Means If You Are Planning the Next Pilot If you are a risk, compliance, or technology leader in a regulated institution and you
Post from toronto banking meeting, Crypto new regulations and how we are adopting and implementing, leadership, lessons learned, hashtags, @ mentions
Crypto Regulation Has Arrived. The Gap Between Policy and Plumbing Is Where Institutions Will Fail. — There is a particular quality to conversations that happen when senior people stop performing and start problem-solving. You can feel the room shift. The language changes. The careful corporate phrasing gives way to something more honest. That is what happened in Toronto last week — and what came out of it is worth documenting properly. I was in a room with banking and fintech leaders working through what the new crypto regulatory framework actually means in practice. Not in theory. Not in a panel discussion designed for an audience. In practice, with people who are responsible for making this work inside real organisations with legacy systems, constrained budgets, and boards who are still not entirely sure what a blockchain is. The conversation confirmed something I have suspected for months. Crypto regulation is no longer approaching. It has arrived. And the industry is discovering, in real time, that being ready in principle is not the same as being ready in operation. — The Room in Toronto The meeting was not a conference. It was a working session — the kind where the agenda has substance and the attendees have skin in the game. Compliance heads. Risk directors. Fintech founders. A few people from the banking side who have been quietly building crypto infrastructure while their public communications remained carefully neutral on the subject. What struck me within the first hour was how consistent the problem was, regardless of the size of the institution or the sophistication of the team. Every organisation in that room had a version of the same challenge. The regulatory expectation was documented. The internal policy existed. The gap was in execution — in the systems, workflows, controls, and data infrastructure that have to translate policy language into daily operational reality. One senior leader said it plainly, without any visible embarrassment: “We have the policy. We don’t have the plumbing.” That sentence has stayed with me. It is the most honest diagnosis of the current implementation crisis I have heard. And it was not said by someone who had been slow or negligent. It was said by someone who had done the right things — engaged legal counsel, built the governance framework, briefed the board — and was now staring at the distance between where their documentation said they were and where their operations actually were. That distance is where the real regulatory risk lives. — Three Things This Told Me First: the speed mismatch is structural, and most organisations have not accounted for it. Regulation moves at the speed of legislation and political will. Operational infrastructure moves at the speed of procurement cycles, vendor negotiations, integration timelines, and internal change management. These are not comparable speeds. Regulatory frameworks for crypto are evolving in months. Core banking systems that need to interface with those frameworks were built over years and are modified in quarters. I have watched this exact dynamic play out before. In AML reform in the late 2010s. In the GDPR rollout. In MiFID II. In each case, the organisations that suffered most were not the ones that disagreed with the regulation — they were the ones that treated the legislative calendar as their operational deadline. They waited for final text. Then they scoped. Then they procured. Then they discovered that the implementation timeline they needed was longer than the compliance deadline they had. Crypto is going to catch a significant number of institutions in exactly this trap. Second: the gap between sophisticated language and operational readiness is wider than most senior teams realise. One of the more uncomfortable dynamics in that Toronto room was the contrast between how fluently people could discuss the regulatory framework and how candidly they acknowledged their execution challenges once the conversation moved past the formal agenda. The policy language, the governance structures, the board presentations — these were polished. The underlying question of whether the transaction monitoring systems could actually flag the activity the regulation required them to flag — that was a different conversation entirely. This is not a criticism of the people in that room. Most of them were operating with significant constraints: technology debt, budget cycles that predate the regulatory shift, and the particular difficulty of explaining infrastructure spend to a board that views crypto compliance as a niche problem rather than a systemic risk. But it is a warning about the gap between what organisations say in regulatory submissions and what their systems can actually execute. That gap is not sustainable. And regulators — particularly as enforcement moves from guidance to action — will find it. Third: the organisations that will lead are already building, despite the uncertainty. This is the pattern I have seen in every major regulatory transition of the past two decades. The winners are not the ones with the most sophisticated legal interpretation. They are the ones who started building operational capability before the rules were final — and who accepted, from the start, that some of what they built would need to be adjusted. This requires a particular kind of institutional nerve. There is always a voice in the room that says: wait for certainty. Do not over-invest in an interpretation that may shift. The voice is not wrong on the logic. But it consistently underestimates the cost of starting late. Waiting for certainty is not a neutral position. It is a choice with consequences — and in regulatory implementation, those consequences typically compound. — What This Means for Your Organisation If you are in a leadership role — compliance, risk, technology, or executive — in any institution with material crypto exposure or ambition, the question is not whether to act. The question is whether the gap between your policy documentation and your operational infrastructure is visible to you before it becomes visible to a regulator or a failure event. The diagnostic is straightforward, even if the answer is not. Can your current systems