The fastest banking teams don’t debate every decision, they rely on clear governance rules that reduce ambiguity, accelerate execution, and maintain accountability.
I watched two teams at two different banks try to do almost the same thing three months apart: bring in an AI notebook tool to speed up a research task. One team spent six weeks in a negotiation that never had a clear owner. Security wanted a review, legal wanted a review, nobody knew who could actually say yes. The tool quietly died on the vine. The other team had an answer inside a day. Not because their bank was more relaxed about risk. If anything, it was stricter. It’s because the rule already existed, it was written down, and everyone in the room knew it before the meeting started.
That’s the whole difference. Not more caution. Less debate.
I call these bright lines: the non-negotiable architecture and security rules for tools, data, and releases. They apply to AI notebooks, vendors, and open source the same way they apply to core code, with no separate lane and no special pleading because something is new and exciting. And here’s the part people get backwards: bright lines don’t exist to slow teams down. They exist so teams stop re-litigating the same argument every time it shows up in a different costume.
Picture a squad automating a manual claims step. Week one, they design it. Risk joins the design session from the start, not the review three weeks later, and flags a data custody problem with the vendor tool the team had their eye on. Bright lines say no, for now. The team doesn’t storm out; they pick a smaller design on the bank’s own platforms instead. It ships faster because it isn’t fighting an exception request. Two months later, adoption is moving and cycle time is down. The slide at the portfolio review looks less impressive than “we’re integrating a new AI platform” would have. Reality is faster.
Or picture the vendor who forces an upgrade nobody asked for, which happens to every bank, every quarter. Score it against the bright lines. The CTO says what’s mandatory and what can wait. One lower-priority item slides down the list to protect Run. That trade gets written down in the project list, not settled in a hallway between whoever happened to run into each other that week.
The mechanism that makes this work is boring on purpose. For each bright line, write a two-page brief covering:
- What the rule is
- Why it exists
- What changes for this team this month
- Who to call when a real exception is warranted
Give managers three sentences they can say out loud in a standup without sounding defensive:
- We’re using canary releases because it lowers blast radius.*
- We ship through the bank pipeline because it makes rollback simple.*
- We’re pausing this scope because the benefit didn’t move off the baseline.*
When people can explain the rule in one breath, they stop treating it as an obstacle and start treating it as a shortcut, because it is one. A platform team that publishes reference code already meeting the bright lines is handing teams a shortcut, not a checkpoint.
None of this is about being risk-averse. High-risk rails (deposits, payments, anything that makes the front page when it breaks) get their own conservative windows regardless. Bright lines are what let everything outside that narrow zone move at speed, because nobody’s re-deciding the same three questions every week.
The teams that move fastest in a bank aren’t the ones with the fewest rules. They’re the ones who never have to argue about which rules apply.
— Rick Mavrovich
