AI won’t replace wisdom
I first met her when she called market turns that saved the bank millions. She could read a balance sheet the way most people read a menu, instinctively, with taste, the numbers arranging themselves into meaning before anyone else in the room had found the right page. Thirty-one years of credit risk experience. The kind of institutional knowledge that doesn’t live in documentation, can’t be onboarded in a fortnight, and walks out the door when people like her retire, leaving quiet devastation in its wake. When we introduced AI-assisted risk tooling last year, she went quiet in every session. Not disruptive. Not vocal in her resistance. Quiet in a way that, if you weren’t paying attention, read as disengagement. I was paying attention, eventually, and what I saw wasn’t a woman failing to keep up. It was a woman calculating, with thirty-one years of precision, exactly how much it would cost her to be seen not-knowing., – Standing in the lift at Canary Wharf on a Tuesday morning in Q3, I kept returning to the session where she sat in the second row. We were running the third onboarding cohort for the new tooling, a mixed group, analysts through to senior directors. I had told myself we were being inclusive by putting everyone in the same room. When the facilitator asked participants to navigate the model interface live, I watched her pause at the screen for slightly longer than everyone else. Not long enough for anyone to notice. Long enough for me to notice. She recovered, clicked through, and said nothing for the rest of the session. Afterwards, I asked her how she found it. She said, *Fine.* And then, after a deliberate beat: *I just need to practice the file saving. The cloud thing.* The file saving. The cloud thing. This was a woman who had built risk frameworks from first principles, who had sat on credit committees shaping the bank’s exposure through two financial crises. She wasn’t struggling with the AI. She was struggling with the visibility of struggling, in front of people she had mentored, whose careers she had shaped, who still sent her questions they couldn’t answer. We had designed the onboarding for capability. We hadn’t designed it for dignity., – We got two things wrong initially. First, we assumed resistance and silence meant the same thing. They don’t. Resistance is a position. Silence is a calculation. When a senior expert goes quiet in a learning environment, they aren’t refusing to learn, they’re refusing to be seen as a beginner in a culture that has spent decades rewarding them for being advanced. These are different problems with different solutions, and conflating them wastes months. Second, we got the architecture of the room wrong. Mixed-cohort onboarding feels democratic. In practice, it creates a quiet social tax on senior participants, who must weigh the cost of every question against the impression it makes on people whose careers they influence. The learning environment we built was technically open and psychologically closed. Openness isn’t the absence of barriers; it’s the deliberate removal of the specific barriers that apply to the specific people in the room. The third thing I didn’t expect was that capability and confidence decouple under observation. She could navigate the tool. What she couldn’t do, not yet, was navigate it in public without the fluency she’d spent thirty years building in every other domain. There’s a particular kind of competence that only exists when no one is watching. Good learning design has to account for that gap, the gap between private ability and public performance, because that’s where most senior professionals quietly give up., – We rebuilt the onboarding from the structure outward. Smaller cohorts. Senior peers paired with senior peers, not because they needed protection, but because psychological safety isn’t an abstract value; it’s a specific condition created by specific design choices. We removed performance metrics for the first sixty days entirely. Progress was measured in questions asked, not tasks completed, because questions are evidence of engagement, and tasks completed can simply be evidence of avoidance. Ninety days after that Tuesday morning, she was running the internal AI literacy sessions herself. Not because we fixed her, but because we fixed the room. The capability was always there. The environment had been charging her too much to use it., – If your AI adoption numbers are disappointing, look at your learning architecture before you look at your people. The dominant assumption, that resistance to AI is about fear of replacement, technophobia, or generational lag, is wrong often enough to be dangerous. In financial services especially, where authority is built on the appearance of knowing, the real barrier is frequently the psychological cost of public inexperience. Your most experienced people are also your most exposed. They have the most to lose from being seen as a beginner, and they will quietly disengage before they’ll let that happen. The organisations that get this right don’t build learning environments that are merely open. They build environments that are specifically safe for expertise, where asking a question is evidence of intellectual seriousness, not a signal of inadequacy. That’s a design problem, not a culture problem. And design problems are solvable. AI won’t replace the woman who can read a balance sheet like a menu. But a poorly designed onboarding session will teach her that learning your tools isn’t worth what it costs, and that’s a loss no model can recover. Wisdom doesn’t need to be replaced. It needs a room where it’s safe to be new.
Why I Built Sovereign AI Infrastructure for Executives
I have experienced a quiet institutional nervousness that never appears in risk registers. It surfaces in a hushed conversation after a long meeting, once the vendor has left and someone, usually the quietest person in the room, asks: *Wait, where does that data actually go?* I’ve been in those rooms. The honest truth is that for most of 2024, we weren’t asking the question early enough. The AI platforms offered to financial services executives today are genuinely impressive. The synthesis capabilities are real. The productivity gains are measurable. And the terms of service are long enough that nobody reads them in full, which I suspect is no accident. What gets buried in that length isn’t necessarily malicious, but it is consequential: the same infrastructure that makes a model smarter for you also makes it smarter about you. Those aren’t the same thing., – What we discovered when we looked closer In early 2024, we ran a pilot: a senior leadership team, a major AI platform, a strategic synthesis use case, the kind of work where you feed a model the texture of how your institution thinks: how it weighs risk, frames optionality, moves from data to conviction. The outputs were good. Genuinely good. The kind that makes you want to scale immediately, and several people in the room were ready to. I wasn’t. And I’ll be honest about why: I hadn’t read the terms carefully enough at the start. When I finally did, properly, with our legal and data governance teams in the same room, we found what we’d half-expected and half-hoped we wouldn’t. Inference rights. Model improvement clauses. Language that was technically precise and strategically vague in exactly the right ratio to be defensible but not transparent. We paused the pilot. That conversation was uncomfortable. Telling a leadership team that the tool works fine but the foundations need examining, after they’ve already started building on them, doesn’t land well. We ran seventeen additional weeks of legal and architectural review before deciding. By then, some of that initial comfort had worn off, which I count as useful., – Three shifts in how I now see this **The executives who grasped sovereignty fastest weren’t the most technical.** That surprised me, until it didn’t. The people who moved quickest were those who’d spent careers in competitive intelligence, deal structuring, proprietary research, people who understood, viscerally, that the way an institution thinks is itself a competitive asset. Information asymmetry is the moat. Once you internalise that, the idea of a third party accumulating inference data on your decision patterns isn’t a technical concern. It’s existential. **Governance deferred is liability accumulated, not risk avoided.** This is the counterintuitive truth I keep restating. There’s a tempting logic: adopt the platform now and sort governance later, when regulations clarify. In financial services, that logic is backwards. Regulations won’t clarify before they tighten. When they do, every institution that treated AI data sovereignty as a procurement footnote will spend considerable energy explaining why. Starting with governance isn’t caution that slows you down. It’s the architectural decision that makes everything else sustainable. **The real risk isn’t that the model knows how you think.** It’s that someone else does. That reframing changes the conversation. We’re comfortable with the idea that AI will learn from our data. Less comfortable, because we haven’t fully faced it, with the idea that the model improving on our data is also improving for someone else’s product roadmap, someone else’s pattern recognition, someone else’s competitive understanding of how major financial institutions make decisions. The custody banks renegotiating data licensing terms in early 2026 weren’t having a price conversation. They were having a sovereignty conversation. The fact that it happened quietly, without headlines, is itself telling., – What this means in practice We’re building infrastructure where the model learns from your decisions without learning for someone else’s benefit. Air-gapped reasoning environments. Institution-owned fine-tuning. No third-party inference trails. This isn’t a political stance or a rejection of external AI capability, we use external models extensively and will continue to. The distinction is between using a tool and feeding a tool. Between a model that improves your decisions and one that improves its understanding of your decisions on behalf of its developer. For any financial services organisation operating at scale, this is now a governance question that belongs alongside data residency, model risk management, and fiduciary responsibility. It’s not a question for the technology team alone. It’s for the board, the risk committee, and especially the executives whose strategic thinking is the asset at stake. The organisations that will manage this well are the ones asking it now, before a contract renewal, a regulatory review, or a competitor’s data breach forces the issue., – The door at the end In two years, the competitive advantage in AI won’t be which model your executives use. It will be whether the insight those executives produce belongs entirely to them.
AI Risk Control Strategy for Global Banking Operations
I first noticed something off in 2022. A tier-one bank’s AI reported zero issues across a full quarter of transaction monitoring. The risk committee reviewed the numbers, saw the clean run, and moved on. False positives were down. Processing time had dropped by sixty percent. By every measure they had, the model worked exactly as designed. A mid-level analyst thought something felt wrong. Not a hunch without reason. She had fifteen years in correspondent banking. Fifteen years watching money move through nested accounts, cross-border flows, paper entities that seemed solid one day and vanished the next. She read those rhythms like a cardiologist reads an ECG, not just the spikes, but the silences that shouldn’t be that quiet., – The Situation She flagged a counterparty. When I asked what had triggered her concern, she hesitated. The honest answer? She couldn’t fully explain it. The flows looked normal. The entity had paperwork. The model had processed and cleared it without a hitch. No single data point stood out. What she had was a shape. A pattern she’d seen before, not identical, but close enough that fifteen years of experience made her notice. The counterparty was structuring: deliberately breaking transactions into pieces to stay below automated detection limits. The method wasn’t new, but the setup, the jurisdictions, the counterparty type, the timing, fell outside the model’s training data. It had never encountered this exact arrangement, so it said nothing. Here’s what haunts me about that year. The model wasn’t broken. It did exactly what it was built to do, precisely. The risk committee wasn’t careless. They reviewed the outputs they were given. The governance process looked correct from every angle it could see. That’s the problem. The system had no visible failure mode for the people responsible for spotting failures. It had no red light. It only had the absence of one, and the organisation had, over time and without anyone saying it aloud, learned to treat that silence as safety., – What Actually Failed The first failure wasn’t the model. It was the way we thought about what the AI was doing. Some AI risk governance treats model metrics as a stand-in for real-world coverage. False positives. Processing speed. Accuracy on test data. These numbers matter. They tell you something real. But they don’t tell you what the model has never seen. A model trained on past transactions will catch patterns it knows. It won’t notice when the world changes, when a new structuring trick emerges, when a rarely used jurisdiction becomes a conduit. It can’t warn you about its own blind spots. That’s not a flaw in design. It’s how these systems learn. The second failure was subtler. When AI metrics look good for long stretches, organisations adjust their human oversight accordingly. Senior analysts spend less time on cleared transactions. Review processes thin out around the automated layer. That makes sense, you wouldn’t manually check every calculation a spreadsheet makes. But the analogy is wrong. A spreadsheet follows rules consistently. An AI model learns patterns from data, and the patterns it never saw are the ones it will never find. The oversight we’re cutting back is exactly the oversight we need to catch what the model misses. The third failure is the one that stays with me. It’s what happened to the analyst’s instinct inside the organisation before that moment. She had flagged things before that didn’t turn into confirmed issues. That’s how real pattern recognition works, not every signal leads to a finding. In some places, repeated flags without outcomes become a professional liability. Analysts learn to adjust their instincts to match what the model approves. The pressure, unspoken but real, pushes toward alignment with the machine. When the machine says nothing is wrong, insisting something is feels risky. Organisations can quietly erode that confidence over time without meaning to., – What This Means for Your Organisation If you run AI-assisted transaction monitoring, or any AI-assisted risk function in a regulated setting, the question isn’t whether your model performs well. It’s whether your oversight is built around what the model cannot see, or whether it’s been quietly reshaped around what the model can process. Those are not the same structures. The institutions getting this right aren’t choosing between AI capability and human judgment. They’re being precise about what each can actually do. AI handles volume and applies learned patterns at a scale no team can match. Experienced analysts spot anomalies outside those patterns, not because they’re better than the model, but because they’re different from it in the ways that count. The gap between the model’s world and reality isn’t something you close by improving the model. You close it by staffing it., – The best AI risk control system I’ve seen wasn’t the one with the strongest model. It was the one that knew, without doubt, where the model ended and what had to happen next. A system that understands its limits is still a system. One that doesn’t is a liability wearing impressive metrics.
AI did not create the fear inside companies. It exposed it.
I have sat in that silence more times than I would like. After a while, you stop hearing it as silence and start hearing it as data. — The Situation In Q1 2022, I was brought in to assess why an enterprise AI deployment had stalled at eleven percent adoption after six months. Let me be precise about what eleven percent means in practice. The system was live, the training had been delivered, the dashboards were accessible, and nine out of ten people who were supposed to be using it had found creative ways not to. Some cited technical friction. Some said the interface was unclear. One memorable response, delivered entirely without irony, was that the tool “did not integrate well with existing workflows,” by which the person meant Microsoft Excel, which they had been using since 2009 and had no intention of replacing. The technology was credible. The vendor was serious. The business case, built over eighteen months, was robust. This was not a situation where a CISO had approved a toy and called it transformation. So I did what I usually do when the obvious answers have already been ruled out: I stopped asking about the technology and started asking about the people. I ran structured sessions with front-line teams and middle management. Not surveys, actual conversations, one level removed from senior leadership so people had some room to be honest. What emerged had almost nothing to do with AI. People were afraid. Not of the AI specifically. They were afraid of being seen to be wrong, afraid that using a new tool meant producing outputs that could be scrutinised, compared, questioned. They had spent years in an environment where errors were punished swiftly and questions were absorbed slowly or not at all. The culture had taught them, with considerable consistency, that visibility was risk. The AI had not introduced that fear. It had simply given it a new surface to sit on. I will be honest: I did not see it immediately. My first instinct, arriving with the brief I had been given, was to look at the implementation, the change management plan, the training quality, the communication cascade. I spent the first week in the wrong territory entirely. The moment I understood what was actually happening came midway through week two, in a conversation with a mid-level analyst who said, quietly, that she would rather do the work manually and be wrong on her own terms than use the system and have the wrong answer attributed to her in a log. That is not a technology problem. That is a decade of learned behaviour, dressed up as a UI complaint. — The Analysis The first thing to understand is that AI systems, by design, make work legible. They create records, trails, decision logs. They answer questions with timestamps attached. In an organisation where accountability has historically flowed downward and rarely upward, that legibility is not experienced as efficiency. It is experienced as exposure. This is the counter-intuition that most AI change programmes miss: the resistance is not irrational. It is a perfectly rational response to an environment where being seen has historically been dangerous. When you introduce a tool that makes every decision more visible, you are not simply adding technology. You are changing the terms on which people have learned to survive professionally. The silence before that resistance sets in is the same silence that kills projects long before any consultant is called in to diagnose them. The second insight is that money spent on AI change management cannot do the work that cultural repair needs to do. I have watched organisations invest heavily in adoption programmes, comms campaigns, lunch-and-learns, executive sponsorship videos, gamified dashboards showing which teams had hit their usage targets, and seen adoption numbers remain stubborn, because none of those interventions addressed what the people in those rooms had actually learned about what happens when you make a mistake in front of the wrong person. You cannot train away a culture. You can only build a different one over time, with evidence. The third point is the one that is most uncomfortable for leadership to hear: if your AI rollout has stalled, the diagnosis is sitting in your own management behaviour, not in the vendor’s implementation. The organisations I have seen successfully deploy AI at scale share one characteristic that has nothing to do with the sophistication of the model or the quality of the data architecture. Senior leaders in those organisations are visibly, repeatedly, publicly comfortable with being wrong. They use the tools themselves, in front of people, and say, “That gave me a result I did not expect, let me work through why.” That one behaviour, modelled consistently, does more for adoption than any change management framework I have encountered. — The Implication If you are leading an AI programme, or sitting on a board that is overseeing one, the question worth asking is not “What is our adoption rate?” The question is: “What does it cost someone in this organisation to be visibly wrong?” If the honest answer is “More than it costs to quietly underperform,” no implementation plan will save you. The technology will land. The adoption will not. And eighteen months from now, someone like me will be brought in to explain why a credible tool with a sound business case is sitting at eleven percent. The answer will be the same answer it always is: the AI was fine. The culture had work to do before the first model was ever deployed. — Closing Organisations do not fear AI. They fear what AI makes visible about the way they have always operated. Fix that first, and the adoption numbers will take care of themselves. AI does not create fear in organisations. It inherits it.
AI Implementation Success: An OCC Compliance Story
When the OCC Said Yes: What a §17f-1 Fix Taught Me About AI in Regulated Finance Regulators do not applaud. They document, they question, they reserve judgement, and occasionally-very occasionally-they express satisfaction. That last phrase, in OCC examination language, is roughly equivalent to a standing ovation from a Scandinavian audience. Last year, when I heard it, I did not celebrate immediately. I went back through the file to check whether we had missed something. We had not. But the reason we had not is more instructive than the outcome itself. — The Situation The custody bank came to me with a §17f-1 problem that had quietly compounded for longer than anyone wanted to admit. Fourteen custodial accounts. Manual reconciliation spread across three jurisdictions-the US, Luxembourg, and a Cayman structure that generated its own particular brand of administrative joy. The average lag between identifying a securities fail and reporting it to the OCC examiner’s desk was eleven days. Eleven days is not a compliance gap. It is a liability with a bow on it. Here is the moment I do not enjoy recounting. In the first working session with the internal operations team, I asked to see the reconciliation workflow. What I expected was a documented process with some inefficiencies. What I found was a spreadsheet. A colour-coded, lovingly maintained, deeply human spreadsheet-owned by one person, checked on her schedule, dependent entirely on her being in the office on a Friday afternoon and not having a migraine. She was excellent at her job. She was also the single point of failure for a regulated function that the OCC takes seriously enough to have its own numbered rule. I had seen versions of this before-in Bahrain, in Mumbai, in London-but something about seeing it at a US custody bank in 2024 still caught me. The gap between what institutions tell regulators about their controls and what actually runs their controls is, in my experience, almost always a person with a spreadsheet and good intentions. We needed to close that gap with something more durable than intention. — The Build The surveillance layer we constructed pulled directly from the core custody ledger-integrated via structured API connections into the bank’s existing custody management infrastructure, which in this case sat on a platform familiar to most mid-tier US custodians. The exception logic ran continuously, not on a schedule. Every identified fail triggered an automated escalation path, timestamped at the moment of detection. SAR-adjacent flagging narratives were auto-drafted and queued for human review before anyone had to open a ticket or send a message. The tooling itself was not exotic. Structured data pipelines, rule-based exception engines layered with a classification model, and a reporting stack that wrote directly to the audit trail in a format the OCC’s examination teams could read without interpretation. Platforms like Nasdaq’s Surveillance infrastructure, Broadridge’s reconciliation and regulatory reporting suite, and AxiomSL (now part of Adenza / Nasdaq) exist precisely for this class of problem. The architecture principles are well understood. What is less understood is why so many institutions still do not implement them until an examiner forces the question. When the OCC review team arrived, they saw real-time audit trails. Timestamped escalation paths. Zero documentation gaps between identification and reporting. The eleven-day lag was gone. The process was no longer dependent on a person remembering to check something. They expressed satisfaction. — Three Things That Were Actually True **First:** the technology was not the differentiator. Every vendor in that room had technology. The differentiator was that the bank finally had a single source of truth-one that did not require a human to remember, to be available, or to interpret ambiguous data under time pressure. The OCC was not impressed by AI. They were impressed by accuracy. AI made accuracy repeatable. That is a meaningfully different claim, and most sales decks in this space get it backwards. **Second:** the eleven-day lag was a symptom, not the disease. The real problem was that no one had priced the exposure correctly. Eleven days of unreported lost or stolen securities is eleven days of regulatory, reputational, and counterparty risk sitting off the risk register. Until you can see the gap in real time, you cannot price it. Until you cannot price it, you will not fix it. Visibility is not a compliance nicety-it is the precondition for every risk decision that follows. This connects to something I wrote about separately: the structural danger hiding inside AI-native clearing approvals, where boards are signing off on automated systems they do not fully understand, compounding the very exposures they believe they are managing. **Third-and this is the one most organisations get wrong-the examiner is not your adversary.** Build for the examiner who assumes the worst. Give them audit trails so clean they have nothing left to question. The institutions that treat regulatory examination as an adversarial event spend enormous energy managing the optics of their controls. The institutions that treat it as a transparency exercise spend that same energy making their controls actually work. One of those strategies scales. The other one ends badly in year three. — What This Means for Your Organisation If your reconciliation workflow depends on a person, a schedule, or a spreadsheet-however capable the person, however reliable the schedule-you are one absence, one error, or one examiner visit away from an eleven-day problem of your own. The technology to close that gap is not emerging. It is available, it is implementable, and in most custody environments it is not even particularly expensive relative to the exposure it eliminates. The question is not whether you can afford to build the surveillance layer. The question is whether you can afford to keep explaining to an examiner why you have not. I have written before about what it looks like when a team holds together under that kind of pressure-the thirty-six-hour stretches, the decisions made at 3am that determine whether the morning looks manageable. None of that replaces the upstream work of building systems
Agentic AI and the OCC Regulatory Stance in 2026
When the Regulator Starts Using the Tool It Is Regulating I’ve seen the moment in any technology cycle when the institution designed to oversee a thing starts becoming the thing. We’re at that moment with AI in banking. The OCC isn’t watching from a distance anymore. It’s inside the machine, learning how it works, trying to understand what it’s being asked to supervise. That should make every bank executive stop and think. Not because it’s threatening. Because it tells you something about where this is going – and how fast. I want to be clear about what I’m not saying. This isn’t a regulatory alarm piece. I’ve written enough of those, and so has everyone else. This is something more specific: an observation about a signal that’s easy to misread if you’re only skimming supervisory documents. — The Document That Stopped Me Last quarter I was working through the OCC’s supervisory posture on agentic AI in banking operations. Not a summary, not a briefing note someone handed me – the actual document. I do this the slow way because the slow way is the only way to catch what the fast way misses. Two things stopped me cold. First, the OCC’s explicit support for agentic AI in automated, compliant banking operations. Not a cautious conditional endorsement wrapped in seventeen qualifications. A directional signal. A federal banking regulator saying: this is the direction, and we’re behind it. In the language regulators actually use, that’s a significant statement. Regulators don’t use words like “support” casually. They have lawyers for that. Second, the same document named both sides of the AI-and-cybersecurity equation in the same breath: AI strengthens cyber defenses and AI sharpens the attacks against the very institutions deploying it. They said both things, explicitly, without softening either one. That kind of candor in regulatory language isn’t standard. Regulatory documents are usually careful to the point of saying nothing. This one said something. Then I found the part about the OCC’s Solutions Lab. GenAI, being used internally, to help the OCC supervise AI-driven tools inside the banks it oversees. I sat with that for a while. The regulator isn’t waiting to understand what it’s regulating. It’s building the capability now, from inside, before the gap becomes uncrossable. I’ll be honest: my first reaction was mild surprise, which immediately became embarrassment at my own surprise. Why would I assume regulators would be passive while the entire sector restructured itself around a technology they barely had working definitions for? Of course they’re building capability. The question is whether they’re building it fast enough – and whether the banks are asking themselves the same question with anything like the same urgency. — What the OCC Is Actually Telling You Agentic AI is no longer experimental in the regulatory view. The OCC’s endorsement of agentic AI for automated, compliant operations is a turning point. It moves AI in banking from the category of innovation-to-be-watched into the category of infrastructure-to-be-governed. That distinction matters enormously. When something is experimental, you can manage it at arm’s length. When something is infrastructure, it has to be understood at depth, by the people responsible for it, not delegated to a team and reviewed quarterly. The OCC has made a judgment that agentic AI is infrastructure. Every board should be making the same judgment about their own posture. The dual-use candor isn’t an accident. Naming both the defensive and offensive implications of AI in a single supervisory document is a deliberate framing choice. It tells banks: we won’t accept the selective narrative. You can’t present AI as a cyber enhancement story while quietly ignoring that the same capabilities are being turned against your systems. The OCC is signaling that it expects integrated thinking – the kind that holds two uncomfortable truths at once without retreating to whichever one is more convenient for the quarterly presentation. The gap that kills institutions is never the technology. I’ve sat in enough post-incident reviews, enough enforcement discussions, enough conversations with executives who genuinely couldn’t explain what their own systems were doing, to know what the real failure mode looks like. It isn’t the AI making a bad decision. It’s the distance between what the tool does and what the leadership team understands about what the tool does. The OCC closing that gap for itself – building internal capability, running its own GenAI in a supervised environment – is the right instinct. It’s the instinct that every bank should be acting on. Not because the regulator said so. Because it’s the only way to govern something you don’t understand yourself. — What This Means for Your Institution A version of AI governance looks correct from a distance. The policies exist. The AI committee meets. The risk register has a section. The vendor attestations are on file. That version of AI governance won’t survive a competent supervisory examination from a regulator that’s now building internal capability to look underneath the surface. The question worth asking – in the next leadership discussion, not the next strategy cycle – is whether your institution’s understanding of its own AI keeps pace with what that AI is actually doing. Not the vendor’s answer to that question. Yours. The OCC is building the capability to ask that question properly. The banks that are ready for it are the ones that asked it first. Understanding your own AI isn’t a governance checkbox. It’s the one audit you can’t outsource.
Overcoming AI Deployment Challenges in Banking GRC
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
Crypto Regulation in Banking: Leadership Lessons Learned
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
When the System Blinks: Understanding and Managing Technology Risk in Financial Services
When the System Blinks: Understanding and Managing Technology Risk in Financial Services One late afternoon, in a well-known financial services firm, a routine end-of-day batch job failed to kick off. A simple scheduling error, it seemed. But that single misfire led to an overnight reconciliation backlog, delayed settlements, and an early morning call with a regulator who’d noticed the delayed reporting. That was the moment we learned: in today’s digitized financial landscape, technology risk isn’t just a back-office concern – it’s front-page news waiting to happen. Technology risk refers to the potential for losses stemming from the failure of systems, software, networks, or third-party tech services. It may be triggered by outdated infrastructure, coding errors, cyberattacks, third-party failures, or even well-meaning automation that no one quite tested properly. The consequences? Reputational damage, financial loss, and regulatory scrutiny. The Chain Reaction Nobody Wants Several years ago, I worked with a global asset manager undergoing a cloud migration. It sounded exciting. The cost savings and scalability benefits were all there. But what wasn’t on the slide deck was how many business-critical applications still depended on legacy architecture that wasn’t cloud-compatible. In one instance, a reporting tool that pulled position data for risk oversight failed to retrieve accurate feeds after the cloud switchover. The result? Inaccurate risk reports sent to internal committees and a scramble to recall and correct them before external eyes got involved. What did we learn? The importance of technology change governance. Before any major tech overhaul, every upstream and downstream dependency needs to be mapped, tested, and retested. Simple rule: if it can break, it probably will – unless you’ve planned for it not to. Cyber Risk: The Ever-Present Shadow No article on tech risk is complete without mentioning cybersecurity. And it isn’t just about firewalls and encryption. A breach can come from an innocuous email attachment. At another institution I advised, a phishing email compromised an employee’s credentials. No big deal, right? Wrong. The compromised ID had access to a dormant third-party file transfer protocol (FTP) server still linked to live customer data. That one oversight turned into a multi-month breach investigation. We took action quickly: reviewed all privileged access, killed off dormant accounts, revamped endpoint monitoring, and launched mandatory cyber-awareness training. But we also rewrote our third-party risk policy to emphasize identity lifecycle management and data minimization. Regulations and Frameworks: A Compass, Not a Crutch Regulators have taken note. The NYDFS Cybersecurity Regulation (23 NYCRR 500), GDPR, and FFIEC guidance all outline expectations for managing tech risk. Yet compliance with these laws shouldn’t be the ceiling – it should be the floor. One client of mine adopted the NIST Cybersecurity Framework as a strategic blueprint. By pairing it with FAIR (Factor Analysis of Information Risk) modeling, we quantified risk exposure in dollar terms. This helped the board better understand why we needed a budget increase for endpoint detection and response. Dollars and metrics speak louder than fear. The People Side of Technology Risk Technology risk is never just about the tech. People build, maintain, and use systems. And people are fallible. At a mid-sized bank, a developer wrote a script that bypassed a manual review step to speed up processing. It worked. Until one day, it didn’t. The script ingested corrupted data, which went unchecked, leading to a cascade of reconciliation issues across six business lines. It took days to untangle. This incident led to our “Human Factors in Technology Risk” initiative. We didn’t just audit the code. We started asking: Why did the developer feel the need to create a workaround? Was it a culture that celebrated speed over controls? Were teams empowered to report fragilities? These are cultural questions as much as operational ones. What Financial Institutions Must Do Map Dependencies – Understand how your systems connect, where the single points of failure lie, and who is accountable for each. Simulate Failure – Run tabletop exercises. Pull the plug (figuratively) on a major system and see what happens. Be surprised in a safe setting. Invest in Culture – Tech awareness, ownership of controls, and a psychologically safe environment to report issues are just as vital as tools and policies. Benchmark to Frameworks – Use NIST, COBIT, ISO 27001, or FFIEC not just for compliance but to drive maturity. Vendor Vigilance – Third-party risk is first-party risk in disguise. Have your vendors been tested? Audited? What’s their incident response time? About the Author Laksh Vaswani is a senior financial services executive and technology risk advisor with over 20 years of experience guiding institutions through digital transformation, regulatory compliance, and operational resilience. A best-selling author and International Achievers Award recipient, he is passionate about building governance frameworks that don’t just satisfy regulators, but make institutions stronger, safer, and smarter. Share this article :