금융 기술 기업 FIS가 화요일 금융 범죄 탐지용 신규 AI 에이전트를 개발했다. 이 에이전트는 앤트로픽이 자체 개발한 커넥터와 템플릿을 기반으로 구축됐으며, 개발 과정에서 앤트로픽의 파견형 엔지니어(FDE) 팀이 내부에 투입됐다.

기업 CIO들은 자체 데이터 품질 문제와 AI 모델 활용의 복잡성으로 인해, AI 벤더의 FDE(Forward Deployed Engineer) 즉 파견형 엔지니어 서비스에 점점 더 많은 비용을 지불하고 있다.

다만 이러한 팀을 어떤 방식과 목적로 도입하느냐에 따라, 기업이 AI 역량을 한 단계 끌어올릴 수 있을지 아니면 끝이 없는 컨설팅 비용 구조에 묶이게 될지가 갈린다.

FIS는 캐나다 몬트리올은행(BMO)과 아말가메이티드 은행을 해당 에이전트의 첫 도입 기업으로 공개했다. 이 에이전트는 은행 핵심 시스템 전반에서 데이터를 수집해 자금세탁 방지 조사 시간을 수시간에서 수분으로 단축하고, 가장 위험도가 높은 사례를 선별해 제공하며 모든 의사결정 과정에 대한 감사 가능성과 추적성을 확보한다.

FIS는 4일 보도자료를 통해 “앤트로픽의 응용 AI(Applied AI) 팀과 FDE가 함께 금융 범죄 AI 에이전트를 공동 설계하고 있으며, FIS가 향후 독립적으로 추가 에이전트를 구축·확장할 수 있도록 지식 이전도 진행하고 있다”라고 밝혔다.

뉴욕 기반 기술 컨설팅 기업 트라이베카 소프트텍의 최고전략책임자 아만 마하파트라는 유사한 AI 벤더 협업을 평가할 때 비용 흐름을 면밀히 살펴야 한다고 조언했다.

마하파트라는 “FIS와 앤트로픽 모델에서 구조적으로 가장 중요한 부분은 실제로 FDE 비용을 누가 부담하느냐”라며 “이는 CIO들이 반드시 던져야 할 질문이지만 대부분 간과하고 있다”라고 지적했다.

가트너의 수석 디렉터 애널리스트 알렉스 코케이루의 최근 보고서에 따르면, FDE 비용은 일부 AI 프로젝트를 위태롭게 만들 수 있다. 코케이루는 “2028년까지 기업의 70%가 높은 벤더 비용과 내부 역량 부족으로 인해 FDE 중심 협업에서 구축된 에이전틱 AI 솔루션을 포기하게 될 것”이라고 전망했다.

소프트웨어가 아닌 ‘서비스’

이 문제는 전적으로 AI 벤더의 책임만은 아니라는 지적이다. 많은 IT 조직이 데이터를 정제하고 AI 활용에 적합하도록 만드는 사전 준비를 충분히 하지 않고 있으며, 조직 내부의 정치적 역학과 개인 간 이해관계도 중요한 변수로 작용한다.

코케이루는 보고서에서 “FDE 성공에 가장 중요한 도메인 전문가일수록 이를 방해할 유인이 가장 크다”라며 “자신의 전문성이 에이전틱 자동화로 흡수된다고 인식한 전문가는 실제 업무 프로세스가 아닌 형식적인 절차만 제공하고, 그 결과 해당 기반으로 구축된 AI 에이전트는 의도적으로 누락된 예외 상황에서 실패하게 된다”라고 분석했다.

이어 “여러 차례 배포 이후에도 FDE 투입 규모가 줄지 않는다면 이는 역량이 아니라 의존성이 형성됐다는 신호”라며 “활용 사례가 성숙해져도 투입 노력이 감소하지 않는다면 기업은 스스로 운영해야 할 영역에 컨설팅 비용을 지불하고 있는 것”이라고 지적했다.

FIS와 앤트로픽 협업 사례에 대해 마하파트라는 “BMO와 아말가메이티드 은행이 분기별 컨설팅 비용 형태로 앤트로픽의 FDE에 직접 비용을 지불하는 구조가 아니다”라며 “FIS가 FDE 비용을 흡수해 전체 은행 고객군에 분산시키는 방식”이라고 설명했다.

이어 “각 은행이 개별적으로 엔지니어링 팀을 구성해 동일한 컨텍스트 경계, 섀도 자율성 통제, 탈옥(jailbreak) 저항 테스트를 반복 수행하는 방식보다 훨씬 경제적인 구조”라고 평가했다.

마하파트라는 이러한 문제의 상당 부분이 생성형 AI와 에이전틱 AI의 마케팅 방식에서 비롯됐다고 지적했다. “AI를 통해 더 적은 인력으로 더 많은 일을 할 수 있다는 초기 ROI 논리는 규제가 엄격한 금융 업무 환경에서는 현실과 맞지 않는 메시지였다”라고 말했다.

보안 AI 연합(CoSAI) 회원이자 ACM AI 보안 프로그램(AISec) 위원인 닉 케일은 FIS의 발표를 두고 “최첨단 AI가 아직 제품 단계에 이르지 못했음을 인정한 것”이라고 평가했다. 이어 “CIO들은 소프트웨어를 구매한다고 생각했지만 실제로는 전문 서비스 계약을 체결하고 있는 것”이라며 “이는 모든 기업 AI 도입에서 비용 구조, 의존성 구조, 거버넌스 모델을 바꾸는 요소”라고 설명했다.

케일은 발표 문구 자체가 에이전틱 전략의 방향성을 보여준다고 분석했다. “FIS는 모든 에이전트 의사결정이 추적 가능하고 감사 가능하다고 밝혔는데, 이는 사실이지만 핵심 질문은 아니다”라며 “진짜 어려운 문제는 에이전트가 어떤 결정을 내렸는지를 검증하는 것이 아니라, 애초에 어떤 결정을 맡길 것인지 정하는 것”이라고 짚었다.
이어 “은행은 수십 년간 의사결정 권한 체계를 구축해 왔지만, 외부 엔지니어가 만든 에이전트 구조에는 이를 그대로 적용하기 어렵다”라고 덧붙였다.

또한 “FDE 팀이 철수한 이후에도 조직이 에이전틱 워크플로를 운영하고, 모니터링하며, 문제를 제기하고, 안전하게 수정할 수 있는지가 CIO의 핵심 판단 기준”이라며 “그렇지 않다면 이는 성공적인 구축 프로젝트일 수는 있어도 아직 기업 역량이라고 보기는 어렵다”라고 강조했다.

컨설팅 기업 액셀리전스의 CEO이자 전 맥킨지 북미 사이버보안 책임자였던 저스틴 그라이스 역시 이 같은 견해에 동의했다.

프로세스로 위장된 인간 판단

그라이스는 “진짜 위험은 비용이 아니라 의존성”이라며 “수십만 달러를 들여 시스템을 운영 환경에 올리는 것 자체는 문제가 아니다”라고 말했다. 이어 “문제는 해당 시스템을 벤더만이 운영하거나 확장할 수 있고, 심지어 완전히 이해할 수 있는 구조가 되는 순간부터 발생한다”라고 지적했다.

일부 컨설팅 구조의 문제는 IT 역량 부족을 가리는 데 있는 것이 아니라, AI 도입 과정에서 ‘지름길’을 허용한다는 점이다.

그레이하운드 리서치의 수석 애널리스트 산치트 비르 고기아는 “FDE에 비용을 지불하는 구조는 에이전틱 AI의 ROI 자체를 훼손하는 것이 아니라, 단순화된 ROI 논리를 무너뜨리는 것”이라며 “이 차이는 매우 중요하다”라고 말했다.

이어 “지난 2년간 기업 AI는 지나치게 깔끔한 인력 절감 스토리로 포장돼 왔다. 모델을 도입하고, 업무를 자동화하고, 인력을 줄여 비용을 절감한다는 식의 접근은 이사회에는 매력적으로 보일 수 있지만 현실을 충분히 반영하지 못한다”라고 설명했다.

고기아는 “대기업은 자동화를 기다리는 정형화된 업무의 집합이 아니라, 예외 상황, 레거시 시스템, 취약한 통합 구조, 접근 통제, 문서화되지 않은 임시 대응, 규제 요구, 그리고 ‘프로세스로 위장된 인간 판단’이 얽힌 복잡한 구조”라며 “FDE는 AI를 실제로 작동하게 만들기 위한 비용 청구서에 가깝다. 이는 혁신이 아니라 더 정교해진 의존성”이라고 강조했다.

또 다른 FDE 관련 우려는 이해 상충 가능성이다. 복잡성을 해결하기 위해 비용을 받는 AI 벤더가, 동시에 그 복잡성의 상당 부분을 만들어낸 주체일 수 있다는 점이다.

프리랜서 기술 분석가 카미 레비는 이러한 비즈니스 구조가 기업의 목표를 저해할 수 있다고 지적했다. 레비는 “AI 에이전트가 조직 전반에서 고도화된 워크플로를 자율적으로 생성·배포·운영하는 것이 목표라면, 기존에 높은 수익을 창출해 온 유지보수 계약 모델과 충돌할 수 있다”라고 말했다. 이어 “고객과 함께 에이전트를 구축하기 위해 FDE를 지속 투입해야 한다면, 장기적인 지원이 필요 없는 수준까지 에이전트를 고도화할 유인이 과연 존재하는지 의문”이라고 덧붙였다.

또한 “FDE 중심 비즈니스 모델이 초기 모델 설계에까지 영향을 미칠 수 있으며, 지속적인 FDE 지원이 필요하도록 AI 플랫폼이 의도적으로 설계됐을 가능성도 있다”라고 분석했다.
dl-ciokorea@foundryco.com

When financial tech vendor FIS announced its new AI agent for detecting financial crimes on Tuesday, it made much of its embedding of a team of forward deployed engineers (FDEs) from Anthropic to make it happen. It’s just one of the dozen or so companies working with Anthropic on developing agents for financial services using new connectors and so-called “ready-to-run” templates Anthropic announced the same day.

Enterprise CIOs are increasingly paying for the services of AI vendors’ FDEs, given their own data quality issues and the complexity of working with AI models.

But how and why such teams are brought in can make the difference between whether the enterprise is helped to get to the next AI level or becomes a hostage to never-ending consulting costs. 

FIS listed the Bank of Montreal (BMO) and Amalgamated Bank as the first two companies to deploy its agent, which it said will compress anti-money-laundering investigations from hours to minutes, assembling evidence across a bank’s core systems and surfacing the riskiest cases for review with full auditability and traceability of decisions. “Anthropic’s Applied AI team and forward-deployed engineers (FDEs) are embedded with FIS to co-design the Financial Crimes AI Agent and transfer knowledge so FIS can build and scale additional agents independently over time,” it said.

Aman Mahapatra, chief strategy officer for Tribeca Softtech, a New York City-based technology consulting firm, suggests CIOs follow the money when evaluating similar work with AI vendors. 

“The structurally interesting thing about the FIS-Anthropic model is who actually pays the FDE cost. This is the question CIOs should be asking but mostly are not,” Mahapatra said.

The cost of FDEs could put some AI projects in jeopardy according to a recent report by Alex Coqueiro, a senior director analyst with Gartner. He predicted that by 2028, “70% of enterprises will be forced to abandon agentic AI solutions from FDE-led engagements because of high vendor costs and lack of internal skills to evolve them independently.”

Service, not software

He argued that the problem is not entirely the fault of the AI vendor. Many IT operations don’t put in the necessary preparatory work to clean their data and to make it AI-friendly. Internal corporate politics/personalities is another critical factor.

“The domain experts most critical to FDE success have the strongest incentive to undermine it. An expert who perceives the FDE as capturing their expertise for agentic automation will give the official process instead of the real one, and the AI agent built on it will fail on the exact edge cases they chose not to mention,” Coqueiro said in the report. “Flat FDE effort across successive deployments is the signal that an engagement has produced a dependency, not a capability. When effort does not decrease as use cases mature, the organization is paying consulting rates for operations it should own.”

In the case of FIS’s work with Anthropic, said Mahapatra, “BMO and Amalgamated are not writing direct checks to Anthropic for forward-deployed engineers at quarterly consulting rates. FIS is absorbing the FDE engagement and amortizing it across its banking customer base.”

That approach, he said, “is meaningfully better economics than direct Anthropic engagements where each bank funds its own embedded engineering team to redesign the same context boundaries, shadow autonomy controls, and the jailbreak resistance testing in isolation.”

Mahapatra said much of this problem stems from how generative and agentic AI have been marketed. The original ROI thesis, he said, was that AI enables enterprises to do more with fewer people, but that was “a marketing pitch that was never going to survive contact with regulated banking workflows.”

Nik Kale, a member of the Coalition for Secure AI (CoSAI) and of ACM’s AI Security (AISec) program committee, said that he sees FIS’s presentation of its work with Anthropic as “a concession that frontier AI isn’t a product yet. CIOs thought they were buying software. They’re actually buying a professional services engagement. That changes the cost model, the dependency model and the governance model for every enterprise AI deployment.”

Kale said the statement’s wording gives a clue about the agentic strategy. 

“The FIS release says every agent decision is traceable and auditable. True statement, wrong sentence. The harder question isn’t auditing what the agent decided. It’s deciding which decisions are the agent’s to make in the first place. Banks have decades of decision-rights frameworks. They don’t translate cleanly to agent harnesses built by someone else’s engineers,” Kale said. “The CIO test is simple: after the forward-deployed team leaves, can your organization still operate, monitor, challenge, and safely modify the agentic workflow? If the answer is no, it’s not mature yet. It may be a successful implementation project, but it’s not yet an enterprise capability.”

Justin Greis, CEO of consulting firm Acceligence and former head of the North American cybersecurity practice at McKinsey, agreed with Kale.

Human judgment pretending to be process

“The bigger risk isn’t the cost of these engagements. It’s the dependency they can create. Spending a few hundred thousand dollars to get something into production isn’t the issue,” Greis said. “Ending up with a system that only the vendor can operate, extend, or even fully understand is where things start to break down.”

The problem with some of these consulting arrangements is not that they hide IT deficiencies as much as they enable AI shortcuts.

Enterprises paying FDE teams “do not undermine the ROI case for agentic AI. They undermine the lazy version of the ROI case. That distinction matters,” said Sanchit Vir Gogia, chief analyst at Greyhound Research. “For the past two years, too much of the enterprise AI narrative has been sold as a tidy labor-reduction story. Buy the model. Automate the work. Reduce the people. Capture the savings. It is neat, board-friendly, and deeply incomplete. Large enterprises are not collections of clean tasks waiting to be automated. They are collections of exceptions, legacy systems, fragile integrations, access controls, undocumented workarounds, compliance obligations, and human judgement pretending to be process. Forward deployed engineers are the invoice for making AI real. That is not transformation. That is dependency with better stationery.”

Another FDE concern is the inevitable conflict of interest that can exist where the AI vendor that is being paid to fix the complexity is also the vendor that created much of that complexity in its model.

Carmi Levy, an independent technology analyst, said the business case can undermine enterprise objectives. “If AI agents are supposed to autonomously create, deploy, and manage super-capable workflows at all levels of the organization, their very capability threatens the future viability of vendors who have long attached lucrative support contracts to those very same deployments. If the FDE is going to be engaged to work alongside customers to make their AI agents come alive, where is the incentive for AI vendors to build agentic systems that are so capable that they don’t require ongoing support? The FDE business model influences up-front model design, and it’s entirely possible that AI platforms are being deliberately designed to require persistent FDE support.”

In early February 2026, markets delivered a powerful reminder of how sensitive industries have become to new developments in artificial intelligence. Software stocks slid after investors reacted to new AI capabilities, and days later, insurance intermediary stocks dropped sharply following news that OpenAI approved a self-service insurance broker application. In less than a week, the software and insurance sectors saw material valuation swings tied to AI sentiment rather than proven outcomes.

These moves aren’t isolated either. Headlines about generative AI tools targeting legal research and workflow automation have also coincided with investor doubt across parts of financial services and knowledge fields. The market reaction was severe and swift — a clear signal that AI can reshape perceptions of value and risk.

Defining AI for your business and your workforce

Strategic AI integration starts with definition. AI today is powerful at pattern recognition, prediction and automation of structured tasks. But it does not think, reason or exercise professional judgment in the human sense. It simulates responses based on training data and statistical relationships, and it can be wrong or “hallucinate” plausible but incorrect results, a risk well documented in research on generative models.

This has real implications in regulated fields such as law, insurance and health care. Only licensed professionals can provide legal or medical advice. AI can augment those professionals — speeding up research or analysis — but it cannot assume responsibility, hold a license or stand in court. The liability and ethical stakes are high.

Instead of viewing AI as a replacement for expertise, CIOs should position it as a force multiplier. AI:

• Accelerates research
• Surfaces patterns in data faster than traditional tools
• Supports decision workflows

But it should not replace professional judgment where outcomes matter. Organizations that treat AI as a co-pilot, not a substitute, protect both quality and trust within their organizations and externally with their customers, vendors and partners.

Building a deliberate AI strategy

To navigate AI disruption effectively, businesses need a clear, offensive strategy that aligns technology with core value propositions. Here are five key priorities:

1. Define AI in business terms

Too often, organizations adopt tools without understanding how they advance organizational strategic objectives. AI is a set of capabilities, not a one-size-fits-all solution. Clarify which problems AI will solve, which outcomes you seek and which risks you must mitigate with its use and alongside its use.

2. Reinforce your value proposition

When markets assume an entire industry might be “done” because of AI headlines, it’s usually because the industry’s value has not been sufficiently articulated. Complex commercial insurance advice, nuanced legal counsel and consultative enterprise relationships cannot be fully commoditized. Leaders must articulate and defend these differentiators to both internal and external audiences.

3. Invest in talent, not just tools

AI’s value is directly tied to the humans who deploy it. Firms must maintain a pipeline of entry-level and mid-career talent who understand both domain context and AI literacy so that future entry-level organizational work is not dependent exclusively on AI. This dual fluency is what separates AI-enabled advantage from tool-driven mediocrity.

4. Communicate team value and vision

Headlines drive fear. Clear, consistent messaging about how AI enhances, not replaces, human expertise strengthens morale and aligns teams with strategic direction.

5. Shift from defensive to offensive

Defensive strategies focus on risk avoidance; offensive strategies focus on growth. Leaders must identify where AI can unlock new service models, improve customer experience, streamline operations and create new revenue streams. Redesigning workflows around AI requires intent, not reaction.

The real impact on work

The debate about AI’s impact on jobs often overlooks a more practical reality: AI is more likely to reshape work than eliminate entire professions and industries.

Workforce projections consistently show that automation will affect significant portions of routine and structured work, but there is no broad consensus that employment will disappear wholesale. Many estimates suggest that AI will both displace and create roles, leading to workforce evolution rather than collapse.

In fact, AI’s measurable productivity and employment effects across industries have yet to emerge. A survey of roughly 6,000 executives across the U.S. and Europe found that nearly nine in 10 firms report no significant productivity gains from AI over the past three years, despite broad adoption of the technology. Similarly, most respondents reported minimal impacts on employment to date, underscoring that early AI usage has been more experimental than transformative.

McKinsey’s most recent global survey supports this mixed picture: Around 88% of organizations say they use AI in at least one business function, but only a minority have scaled AI programs across the enterprise or seen material enterprise-wide financial impact.

Talent constraints are slowing AI progress. Industry surveys consistently show that organizations struggle to find professionals with the technical and governance expertise needed to scale AI beyond pilot programs. That imbalance has implications beyond staffing numbers. It affects how all organizations grow, innovate and compete.

The more useful question for CIOs is not how many jobs AI will remove, but how work will be redesigned. AI is not a one-time disruption; it is an ongoing shift in how technology integrates with business strategy. Markets will react to headlines, sentiment will fluctuate and new capabilities will spark fresh waves of optimism and anxiety. Over time, however, AI will simply become part of the enterprise operating environment.

Organizations that navigate this well will not treat AI as either a threat or a cure-all. They will define how it fits their model, invest in talent alongside tools and strengthen the human expertise that sets them apart.

The real question is not whether disruption will continue, because it will. Instead, ask yourself how deliberately you choose to deploy AI when it is in your control.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

“La confianza es una ventaja competitiva”. Con estas palabras comenzó ayer Víctor Yubero, director de Gobernanza de Inteligencia Artificial del Banco Sabadell, su intervención en el evento CIO ForwardTech & ThreatScape Spain, organizado por las cabeceras CIO y COPMUTERWORLD en España y celebrado ayer en Madrid. Porque, al igual que ocurre con otros sectores, las últimas tendencias en inteligencia artificial (IA) generativa, junto con el auge de los agentes, están transformando profundamente los procesos de negocio y la forma de trabajar del sector bancario.

Palabras que tienen su explicación: en banca, la confianza no es un tema de marketing, tal y como reconoció Yubero, pues “llevamos mucho tiempo en este negocio y estamos acostumbrados. Lo es todo”. En consecuencia, el sector bancario en particular está virando de la confianza monetaria a la algorítmica. Una transición suave, en su opinión, pues “la IA introduce una nueva capa de riesgo debido a decisiones invisibles por culpa de esos algoritmos”, por lo que “esto se debe de gestionar de manera igual de rigurosa que cuando se gestiona un producto bancario, como es el caso de una hipoteca. Si no somos capaces de transmitir confianza, el negocio no funciona”.

España como modelo europeo de confianza

En este escenario, España es un modelo europeo de confianza en lo que la IA respecta, tal y como admitió. En opinión de Víctor Yubero, el sector bancario parte, además, de una posición diferencial debido a su amplia experiencia en entornos regulados. “Está habituado a operar bajo estrictos marcos normativos, con altos niveles de control, trazabilidad y supervisión”, por lo que “esta experiencia facilita la adaptación a las nuevas exigencias regulatorias en inteligencia artificial, como las derivadas del futuro marco europeo, y permite anticiparse a muchos de estos requisitos”.

En consecuencia, el director de Gobernanza de Inteligencia Artificial del Banco Sabadell reconoció que España se está posicionando como un referente en IA responsable, en parte gracias a iniciativas como el sandbox regulatorio. Este entorno permite probar casos de uso de alto riesgo en condiciones controladas, fomentando la innovación sin comprometer el cumplimiento normativo. Además, está contribuyendo a generar guías y buenas prácticas que pueden convertirse en referencia a nivel europeo.

La necesidad de la explicabilidad y la trazabilidad

En un momento de su intervención, Víctor Yubero destacó el gran valor de la explicabilidad y la trazabilidad, pues sin ellas la IA no puede escalar de forma sostenible. “La explicabilidad —explicó— permite justificar decisiones ante clientes y reguladores, facilita la supervisión interna y refuerza la confianza. Por ejemplo, en un modelo de concesión de crédito, es necesario poder detallar qué factores han influido en la decisión y en qué medida”.

A lo que unió la necesidad de mantener una supervisión efectiva. Yubero destacó que los sistemas deben proporcionar información suficiente para que los analistas puedan entender y validar las decisiones, especialmente en ámbitos como la detección de fraude. “Sin esta capacidad, no es posible garantizar un control adecuado ni ofrecer respuestas claras ante posibles incidencias”, añadió.

Garpress | Foundry

Aplicación práctica

En cuanto a la aplicación práctica, Víctor Yubero expuso distintos casos de uso dentro del sector bancario. Entre ellos destacó modelos de scoring crediticio más explicables, el uso de IA generativa en la interacción con clientes y empleados, y sistemas avanzados de detección de fraude multicanal. “En todos estos casos, es necesario garantizar la transparencia, establecer límites claros de actuación de los sistemas y mantener siempre la posibilidad de intervención humana”.

No obstante, y fue la reflexión con la que terminó su intervención en el CIO ForwardTech & ThreatScape Spain, “la clave del éxito no reside únicamente en la tecnología, sino en la confianza que esta genera. Las organizaciones que logren desarrollar sistemas en los que confíen sus clientes, reguladores y la sociedad serán las que obtengan una verdadera ventaja competitiva”.

I spent years at Meta engineering large-scale systems for billions of users, delivering sub-second latency and five-nines (99.999%) uptime. When we started Outmarket AI, I brought that same lens: scalability, reliability, sustainability. Not buzzwords but real engineering.

Commercial insurance turned out to be a different planet. Some departments were still on pen and paper, going through manila folders. Others had systems built on COBOL, mainframes from the 80s to handle claims. Nobody wants to touch them because the guy who understood the code retired years ago and didn’t leave notes. Underwriters, brokers, marketing, customer reps — everyone going through thousand-page policy documents, making million-dollar calls for businesses. According to McKinsey’s State of AI research, 78% of organizations are using AI in at least one business function. Insurance has been slower to change the way it operates day to day.

We started building AI products for a few lines of commercial business: workers’ comp, general liability and property coverage to better understand all the pain points. Consider workers’ compensation, which in itself is a beast. A human has to analyze injury claims, workplace risk factors, OSHA reports, medical records, claims histories and state regulations that differ wildly. For general liability, one has to dig through premises risk, operations exposure, vendor agreements and similar hassles for property coverages. Meaning a single policy decision might need someone to pull together dozens of documents from different sources and spend more time on clerical work as opposed to the real deal

Within weeks, our first client wanted it for every other line of business. Not just one department, but the entire organization. The pattern repeated with every new client as they quickly realized the same AI infrastructure could transform how they handled all of their commercial policies. That moment crystallized something for the founding team. We weren’t building a feature, but instead building an AI-backed infrastructure and I knew exactly what that meant from my time engineering at scale.

The AI part wasn’t what kept me up at night. Large language models (LLMs) can handle dense insurance documents. That’s been proven. What worried me was everything underneath.

First, scale. How do we build something that grows with more clients? And scale by users per client? What about seasonality when commercial insurance policy renewals peak? Q4 is a mess. Traffic doesn’t grow linearly. It spikes ~10x.

Second, reliability. We started with one LLM provider. It worked fine, but what will happen when traffic spikes? Everyone’s slamming the same LLM. That’s a nightmare of hitting rate limits, token limits. What if third-party systems go down? We all have seen this in action when ChatGPT went down

Third, data isolation. No insurer would tolerate its proprietary underwriting data bleeding into a competitor’s context window. Every client needs their own guardrails.

So we weren’t just building a system. We were building a beast that can’t flinch under pressure, can’t go dark when a provider fails and can’t leak data between clients.

We attacked each problem head-on.

For isolation, we went single-tenant. Every client gets their own instance, their own database, their own AI context boundary. No shortcuts.

For reliability, we designed the load balancers of AI agents that look at everything and most importantly, latency, cost, accuracy needs, provider health and make a call in real time. If one provider is down, it is now obvious that the traffic has to shift.

This orchestration layer was the breakthrough that can scale infinitely now.

Why is insurance the ultimate stress test for AI infrastructure?

Think about a mid-sized restaurant chain buying commercial insurance. They need workers’ comp for kitchen staff, general liability for slip-and-fall incidents, property coverage for equipment, outdoor dining coverage, liquor liability, theft protection. Probably a dozen policies total. And these are all thousands of pages of dense legal language, exclusions, endorsements, coverage schedules and many more.

Before AI, someone had to read all of this manually. Risk managers spent weeks on it, sometimes months, comparing quotes from various carriers, hunting for gaps, trying to catch redundancies and all of this manually. The mental load was brutal and mistakes were inevitable. I have seen claims denied because of a coverage gap buried on page 847 that no one saw. The policy looked fine. The exclusion that mattered was hiding in plain sight. When that happens, insurers fall back on their errors and omissions coverage (E&O) to protect against mistakes made by their employees while reviewing insurance. That’s how broken the manual process is and can easily lead to millions of dollars in claims.

A typical policy bundle containing 2K pages can now be ingested in 10 to 15 seconds. Even though speed is a big win, what’s more exciting are things that were not possible before. Quotes from various carriers can now be compared side by side in real time. AI flagging gaps automatically before they turn into claim denial. Underwriters can type questions in plain English. “Does this cover water damage from a burst pipe in an unoccupied building during winter?” Answer with citations to gain more trust and confidence. No human can process with that speed and accuracy. The humans are now reviewers and decision-makers and not document processors.

Surviving seasonality: Engineering for 10x traffic spikes

Insurance has a brutal seasonality problem. Policy renewals cluster around year-end. As soon as Q4 hits, traffic is expected to spike by ~10x. An architecture that runs fine in March can collapse in December if we haven’t planned for it.

Three things kept me up. First, caching. LLM caching is not like a typical web caching. Take these two questions, for example:

1. “What’s my deductible for property damage?”
2. “How much do I pay out of pocket for building damage?”

Both are basically the same question. How do we recognize that and not waste compute power?

Second, scaling. When renewal season hits, the largest client might need 10x the capacity overnight, but I don’t want to pay for that capacity year-round.

Third, routing. Not every query to LLM needs the biggest and the best model. A simple policy lookup doesn’t need the same horsepower as a complex one. Sending everything to one model means simple queries wait behind heavy ones.

We tackled each one.

For caching, we have semantic matching algorithms at multiple levels.

1. At the embedding level: We cache vector representations so re-injection would re-use the same embeddings.
2. At the query level: We use locality-sensitive hashing to spot similar questions and serve cached responses. If a question is already answered, then a similar question can use the same response without burning the compute power twice.

For scaling, each worker process can auto-scale horizontally based on queue length and current latency in-place. The largest client might go from 4 workers to 40, then scale back as soon as traffic drops. The key here is that scaling can be reactive, but for seasonalities, it can be predictive. If client X’s renewal rush started October 15th last year, then we can technically pre-warm their infrastructure on October 10th this year.

For routing, we built a classifier that examines incoming requests and sends them to the right model. A simple lookup can use a small, fast model; however, a complex coverage analysis workflow can be routed to more sophisticated models. This can cut cost by about 40% and actually improve P95 latency because simple queries are not jammed behind complex ones.

Now let’s put this together and we see users getting sub-second responses irrespective of quiet Tuesdays or chaotic Decembers. That consistency is what turns AI to what people can use at scale.

AI hallucinations kill trust; domain knowledge fixes it

Large Language Models (LLMs) fail in ways that regular software does not. In traditional software engineering, a database either returns the right row or throws an error, but an LLM will always return plausible-sounding nonsense and any system will happily pass it downstream unless we build detection mechanisms. Research published in Nature has shown that detecting these “confabulations” (arbitrary and incorrect generations) requires measuring uncertainty about the meanings of responses, not the text alone.

The root cause depends on how all these models learn. General-purpose LLMs train on public data crawled from the internet. They’re capable of broad reasoning without any domain expertise. If we ask a general LLM about insurance policy structure, it will give a reasonable-sounding answer drawn from insurance data that exists in its training set, which may or may not reflect the actual terminology, coverage structures and regulatory requirements that clients operate on. In any insurance, a reasonable-sounding yet wrong answer can lead to denial of claims or even regulatory violations, leading to millions of dollars in losses

Research on fine-tuning LLMs for domain knowledge graph alignment has demonstrated that when models are tuned to domain knowledge, then it can perform multi-step inferences while minimizing hallucination. So we built out our own knowledge graph for insurance, which holds definitions of how the industry actually works. Coverage types, policy structures, regulations, carrier-specific terms, claims workflows, how everything connects. It took years of domain expertise to build it and we are still fine-tuning it every time we run into a weird edge case. What we found out was that when our models were fine-tuned against this custom graph, they stayed inside verified boundaries instead of inventing plausible-sounding answers from pre-trained public data.

In practice, this makes a huge difference. If a user asks for coverage exclusions, then the system no longer hallucinates. It uses a knowledge graph as a source of truth. Any missing knowledge in the graph means uncertainty rather than confabulating an answer.

No system is perfect, though. Even with the knowledge graph, things slip through. I call it hallucination tripwires, an automated check that can catch AI when it’s making stuff up.

Model claims a coverage limit that’s nowhere in the source document? Tripwire.

Model references a policy section that doesn’t exist? Tripwire.

Model pulls a number that’s way outside expected ranges for that policy type? Tripwire.

An ACM survey on LLM hallucinations categorizes hallucination detection techniques into two: factuality and faithfulness approaches. When a tripwire triggers, a smart system won’t just log an error and move on. It will fall back to a secondary model for verification purposes. And when that fails, it will escalate to a human for review, depending upon the severity and confidence scores.

Hallucination detection is one piece. The other is model drift. Models can get worse over time and shift away from training data and accuracy drops. We track this constantly, checking against human-verified samples. When we see the numbers trending down, we fine-tune or adjust our prompts. Observability isn’t a nice-to-have; it’s a must for enterprise applications to stay reliable and win clients’ trust.

Databricks popularized a concept called medallion architecture, where raw ingestion produces what we call “bronze” data, minimally processed, potentially messy. AI-driven normalization transforms this into “silver” data with consistent schemas and validated fields. Further enrichment and cross-referencing produce “gold” data that’s ready for downstream analytics and reporting. This tiering can help serve different use cases appropriately. Real-time policy queries can work against silver data, whereas regulatory reporting and actuarial analysis must work off of gold-tier data with full audit trails.

Engineering principles that made the difference

A few principles that stand out when I look back in time.

AI is an infrastructure. Treat it that way from day one. Don’t bolt on scalability later. The early decisions on single-tenant v/s multi-tenant, sync or async, one LLM provider or several will compound. Unwinding them later will be painful and expensive as it may eat up a good amount of engineering resources and time and even get new features to stand still for weeks to months.

Build for failures. Providers go down, models hallucinate and demands can go up at any time, especially when we least expect it, so build the fallback paths before entering panic mode.

Observability is not optional. In regular early-stage software, we can skip the fancy monitoring, but in later stages, especially with AI systems, we can not afford to do that. No observability will mean shipping a broken output and being blindfolded about it.

Commercial Insurance has built its traditional processes around human limits, especially reviewing speed and mental bandwidth. AI can lift those limits up if and only if the infrastructure holds up to its expectations reliably, at scale and under pressure.

The difference between an AI demo and an enterprise AI system is not the AI models but the backbone, the infrastructure that doesn’t flinch.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

Years ago, around 2015, while working on a digital wallet integration initiative at Lloyds Bank, I realized something fundamental: modern payment capabilities are not traditional software projects.

Digital wallets such as Apple Pay changed how financial institutions design, deliver and govern technology. What appeared externally as a simple “tap-to-pay” feature required deep coordination across device manufacturers, payment networks, security standard bodies, regulators and banking platforms.

Today, as organizations integrate AI platforms, embedded finance and partner ecosystems, the same complexity patterns are repeating.

This article shares the practical lessons for designing and delivering complex requirement ecosystems, using digital wallet integration as a reference model.

Why this was not a normal requirement

Traditional banking delivery assumes:

• Clear ownership of systems
• Stable requirements
• Internal control over timeline
• Predictable testing environment

Digital wallets broke all four assumptions. Instead, delivery depended on:

• Security-first architecture constraint
• Payment network standards
• Continuous Requirement evolution
• External platform certification

By 2025-2026, digital wallets facilitated tens of trillions in global transaction value annually (e.g., estimates place combined digital wallet volumes at $10-40+ trillions in recent years), with user bases exceeding 4-5 billion globally and hundreds and millions for a leading platform like Apple Pay.

For Apple Pay specifically, recent estimates show approximately 800 million+ users and approximately $9-9.5 trillion in transaction volume in 2025, making it the second-largest payment processor behind Visa.

The lesson I learned: When a requirement depends on an external platform, you are no longer building a product; you are joining an ecosystem.

Start with ecosystem architecture, not solution architecture

One of the most common mistakes organizations make is jumping directly into solution design.

Complex integration design requires mapping the ecosystem first.

Key questions leaders must answer early:

• Who owns customer identity?
• Where in the architecture and who controls security division?
• What components require external certifications?
• Which dependencies are outside delivery control?

In a payment ecosystem, multiple parties collaborate to enable a single transaction.

• Device platform provider
• Issuing bank
• Card networks
• Token service providers
• Merchant and acquirers

Requirement documents may quickly become outdated if the ecosystem mapping is not properly mapped.

Requirements must become adaptive, not static

The platform rules evolved continuously. Security standards updated. Certification expectations changed. Integration Interfaces matured.

Successful teams shifted from documentation-heavy approaches toward:

• Capability-based requirement
• Incremental approval checkpoints
• Continuous partner validation
• Outcome-focused design

Instead of asking: “What are the final requirements?” The team focused on “What capabilities must remain stable even if implementation changes?”

Security is the architecture, not a phase

Digital wallets introduced a major architectural shift; payment systems stopped transmitting the real card numbers

Instead, they rely on payment tokenization standard developed by EMVCo, where a unique token replaces the actual card number during transactions. This replaces the sensitive Primary Account Number (PAN) with a device- or domain- specific token, rendering stolen data far less usable to fraudsters.

You can explore how tokenization works here: EMV Payment Tokenization Overview.

This approach dramatically reduces fraud risk because stolen tokens cannot be reused outside their intended context.

For engineering leaders, this creates a critical realization that Security constraints drive architecture decisions long before functional design begins.

Security became the foundation of the design.

Operating models must evolve

Complex integrations expose organizational bottlenecks quickly.

Traditional silos, business, security, engineering and compliance slow delivery when decisions must happen rapidly.

Successful delivery required:

• Embedded risk and compliance participation
• Architects involved from ideation
• Faster decision-making authority

The hidden leadership lesson: Orchestration over ownership

Digital wallet integration previewed the future of enterprise technology.

Organizations no longer control the entire system.

Instead, success depends on orchestrating capabilities across independent platforms.

This shift is visible today in:

• Embedded finance ecosystem
• Open banking APIs
• AI Platform Integrations
• Cloud-native partner marketplaces

Leaders must evolve from system owners to ecosystem orchestrators.

A practical framework for designing complex requirements

Based on real delivery experience, leaders can apply this framework:

• Identify ecosystem complexity early. If success depends on external platforms, treat it as an ecosystem program.
• Design governance before architecture. Alignment mechanism reduces delay more than technical optimization.
• Make security a design driver. Security models shape system boundaries.
• Define capabilities, not fixed requirements. Assume change is inevitable.
• Align operating model to dependency speed. Decision latency becomes the biggest delivery risk.
• Build integration maturity as a core capability. Future competitiveness depends on how well organizations integrate, not just build.

A new delivery paradigm

What looked like a payment feature was actually a preview of modern digital transformation.

The real innovation was not contactless payments; it was a new delivery paradigm where value emerges from a coordinated ecosystem rather than standalone systems.

Today’s most complex initiatives, like AI adoption, platform integration and digital partnerships, follow the same pattern.

Organizations that learn to design for ecosystem complexity will deliver faster, safer and with far greater resilience. Will your organization treat the next big iteration as a feature or as an ecosystem transformation?

This article is published as part of the Foundry Expert Contributor Network.
Want to join?

War is already changing the operating conditions for banks faster than most planning systems can respond. This article uses banking as its primary lens, but the underlying challenge — planning systems that cannot absorb change fast enough — applies across most industries.

That is the real issue.

I have spent a large part of my career working on planning systems, portfolio decisions, and executive teams, trying to make sense of change while the ground was already moving beneath them. One lesson keeps repeating itself: organizations rarely fail because they did not produce a plan. They fail because reality changed faster than the planning system could absorb.

That is where banks find themselves today.

As of April 2026, war is no longer a geopolitical backdrop to financial services. It is a live, operating variable that shapes markets, liquidity, sanctions exposure, and cross-border payments in real time. In a Reuters interview, IMF Managing Director Kristalina Georgieva said the war will mean “higher prices and slower growth” even if it ends soon, because the disruption to energy and supply channels is already feeding through the system. The same report noted that the disruption around the Strait of Hormuz is affecting a route that carries roughly one-fifth of global oil and gas flows.

For banks, that is not the macro context.

It is the operating environment.

Why static planning is now dangerous

Our current environment is why continuous scenario planning has moved from a good discipline to a core requirement. In wartime, annual planning is dangerous. Quarterly planning is slow. I would argue that anything less than weekly planning is now dangerous for globally exposed banks, because the variables that matter most can change inside a single board cycle.

The existing planning model was built for a different world. A bank could set an annual strategy, align budgets, review quarterly, run periodic stress tests, and treat disruptions as exceptions. But regulators and markets are now signaling that the exception has become the norm. The European Central Bank has made resilience to geopolitical risks and macro-financial uncertainty a supervisory priority. In 2026, it will conduct a reverse stress test on geopolitical risks across 110 directly supervised banks. That matters because the ECB is not simply handing banks a standard scenario and asking whether they survive. It is asking each institution to define the path by which geopolitical events could drive severe capital depletion.

That is a profound shift.

It means supervisors are effectively saying: do not just tell us you can survive a known shock. Show us that you can think dynamically about your own vulnerabilities before the next shock hits.

How shocks actually hit a bank

The problem with war-driven disruption is that it does not fall neatly into one category. It arrives as a chain reaction.

A conflict intensifies. Energy prices rise. Inflation expectations shift. Rate cuts get delayed. Funding assumptions change. Corporate borrowers in the transport, manufacturing, agriculture, and energy-intensive sectors are under greater pressure. Hedging behavior changes. Clients move money differently. Sanctions expand. Cross-border payment flows become more complex. Compliance teams must review exposures and counterparty relationships faster. Treasury, risk, operations, technology, and the business all need answers at once.

That is not a single issue.

It is a system problem.

And that is exactly where static planning breaks. The arithmetic is moving while the plan is standing still.

Take one realistic example. Reuters reported that UBS lowered its 2026 S&P 500 target because the Middle East conflict pushed oil prices higher, increased economic uncertainty, and delayed expected Federal Reserve cuts. Since the outbreak of the Iran war on February 28, the S&P 500 has fallen about 3.9 percent, according to that report.

Now translate that into a bank’s actual management problem.

If oil stays elevated for months, that is not simply a market call. It affects the credit quality outlook for specific sectors. It changes treasury assumptions. It alters customer behavior. It can simultaneously pressure deposit flows, lending appetite, capital allocation, and operating costs. That broader financial stability concern was echoed by ECB Governing Council member Fabio Panetta, who warned Reuters that the energy shock was raising financial stability risks. If the institution is also in the middle of a cost program, a core modernization effort, or a remediation exercise, the same scarce people may be required in multiple places simultaneously.

This is the kind of moment when the board asks a perfectly reasonable question:

What do we stop, what do we protect, what do we accelerate, and what is the consequence of each choice?

Traditional planning does not answer that question well. It usually answers a different question: what did we think the year would look like when we approved the budget?

What continuous scenario planning changes

Continuous scenario planning starts somewhere else. It asks what changed, which constraints moved, which dependencies are now binding, and what tradeoffs leadership has to make before the cost compounds.

Annual planning is calendar-based.

Continuous scenario planning is trigger-based.

Annual planning assumes the world will pause for review.

Continuous scenario planning assumes the world will not.

That matters because several of the pressures hitting banks now are not transient annoyances. They are structural conditions. The IMF is warning about slower growth and higher inflation from the current conflict. Andrew Bailey, speaking as chair of the Financial Stability Board, warned that “frictions in international payments have the potential to act as a driver of fragmentation of the global system” in a March FSB speech.

Put differently, banks are not dealing with one shock. They are dealing with a more fragmented operating order, a point the ECB and ESRB underscored when they warned that geopolitical shocks can lead banks and non-banks to reduce lending, especially cross-border exposures.

Sanctions and payments are now operational risk

That fragmentation shows up in sanctions and payments as clearly as anywhere and is no longer just a back-office compliance matter. When sanctions expand or diverge across jurisdictions, global banks have to think through counterparty exposure, corridor reliability, client obligations, correspondent relationships, liquidity flows, and operational bottlenecks together.

That is not theoretical. In February 2026, Reuters reported that U.S. regulators proposed cutting Swiss private bank MBaer off from the U.S. financial system over alleged links tied to Iran, Russia, and Venezuela, a reminder that sanctions risk can quickly become an existential operating issue for a bank. Bailey’s warning about payment friction matters because it points to something many leadership teams still underestimate: the plumbing itself is becoming geopolitical.

Imagine the practical version. A multinational bank with operations in Europe, Asia, and the Gulf wakes up to a sanctions escalation tied to a military event. Certain counterparties become restricted. Some clients need urgent payment rerouting. Compliance wants more review. Relationship managers want client continuity. Treasury wants to understand liquidity effects. Technology teams are suddenly dealing with workflow changes and control logic. The executive committee wants to know, by tomorrow morning, the revenue and risk impacts, and which commitments elsewhere in the portfolio need to be moved now.

That is not a better dashboard problem.

That is a scenario problem.

The CIO mandate is changing

Many banks still understate the CIO’s role here. This is not only a strategy issue or a risk issue. It is a systems issue. The current architecture in many institutions was not built to support live, cross-functional consequence modeling. Data sits in separate systems. Capacity is tracked in one place, financial assumptions in another, execution commitments in yet another, and regulatory obligations in yet another. During stable periods, the seams are tolerable. Under geopolitical pressure, they become expensive.

The CIO’s mandate is changing as a result. It is no longer enough to ensure that the bank has strong systems of record. The harder challenge is to make those systems usable when decisions are being made.

That means three things:

1. Reduce the distance between risk, finance, payments, and portfolio data. If each function has to build its own answer after every shock, the bank is already late.
2. Create a planning environment where leadership can test scenarios across the same set of constraints. Not treasury in one model, compliance in another, and transformation in a slide deck. One environment. Shared assumptions. Visible tradeoffs.
3. Shift from reporting cycles to trigger cycles. If sanctions change, an energy shock, or a payments disruption can alter the bank’s risk posture in days, then the planning system has to move on that clock as well.

That is the directional answer for CIOs. Build the connective tissue that lets the institution compare consequences before separate functions lock in separate responses.

The good news is that most banks already have the raw ingredients. ERP systems hold the financial data. PPM or PMO platforms track the portfolio of change. SPM tools carry strategic priorities. Project plans, capacity models, and even well-structured spreadsheets contain the operational detail. The data problem in most institutions is not one of absence. It is one of fragmentation. What has changed is that the technology to connect those sources into a common planning environment now exists, and AI-driven interfaces mean that a CFO, CRO, or CEO can query that connected environment in plain language, asking the kind of questions that used to require a team of analysts and a week of lead time. The barrier is no longer technical. It is organizational will.

How banks actually build the capability

How do banks get there without turning this into another expensive transformation initiative?

In my experience, they do not start by modeling everything.

They start by choosing one decision arena where geopolitical shocks already create visible stress. It might be sanctions and payments. It might be energy-sensitive credit exposure. It might be liquidity and funding assumptions. The point is to begin where a shock can simultaneously move earnings, risk, and operations.

From there, the path is more practical than many leaders assume:

1. Connect the few data streams that determine the decision. Risk, finance, payments, capacity, and the active change portfolio usually matter more than another round of presentation material.
2. Define the triggers that force a scenario review. A sanctions change. A corridor disruption. A commodity spike. A rate shift. A supervisory action. If the trigger is real, the review should be immediate, not deferred to the next reporting cycle.
3. Establish a weekly executive cadence for scenario comparison. Not a status meeting. A decision meeting. The question is not what changed in each silo. The question is: what does the bank now need to protect, slow, accelerate, or stop?
4. Make tradeoffs explicit. If the institution prioritizes liquidity resilience, what gets delayed? If it protects payment continuity, which transformation resources move? If it accelerates one control program, what capacity disappears elsewhere?

Continuous scenario planning now becomes operational, not as a new planning religion, but as a repeatable discipline for making better decisions under pressure.

Banks do not need to perfect this across the entire enterprise on day one. They need to become faster and more coherent in the places where shocks are already forcing hard choices. That is usually how the capability starts.

The market is already moving

The question is not whether the bank has data. Of course it does. The question is whether it can connect the data quickly enough to calculate the next consequence before management is forced into guesswork.

The market examples from the last year should be sobering. Reuters reported that tariff turmoil cast a pall over European banks’ earnings outlook in 2025 as trade stress hit confidence, credit expectations, and sector valuations. And in March 2026, J.P. Morgan warned via Reuters that HSBC and Standard Chartered were among the European banks most exposed to the Middle East conflict, underscoring how unevenly geopolitical shocks can land across institutions and portfolios.

The market does not wait for the next planning cycle.

The stronger signal is operational, not rhetorical. Supervisors are forcing banks to design reverse-geopolitical stress scenarios because standardized exercises are no longer sufficient. Markets are repricing institutions unevenly when conflict exposure becomes clearer. And when trade shocks or sanctions changes hit, the effect does not stay inside one function. It considers earnings expectations, sector risk, payments, and capital allocation simultaneously.

What real-time scenario planning looks like in practice

What does that look like in practice?

It means a bank can stop arguing over whether a shock matters and start testing what it does.

Imagine a leadership team on a Tuesday morning after an overnight escalation. Oil is up. Sanctions lists are changing. A key payments corridor is slowing. The traditional response is a flurry of calls, separate spreadsheets, and each function building its own partial answer. Treasury models liquidity. Risk reviews sector exposure. Compliance checks counterparties. Technology assesses workflow impact. The executive committee gets fragments, not a usable picture.

Instead of asking each team for a static update, leadership can test a live set of scenarios. What happens if oil stays elevated for ninety days instead of thirty? Which client segments move from watchlist to immediate concern? What if sanctions are widened to include adjacent counterparties, or if a payment route becomes unreliable? Which programs lose capacity first because the same people are now needed for control changes, client support, and remediation work? Which commitments should be protected because they stabilize the bank, and which should be deferred because they consume scarce talent without improving resilience?

That is the difference. The point is not simply to produce a more elegant plan. The point is to give leadership a way to compare consequences before they commit.

A good continuous scenario discipline also forces hard choices into the open. If the bank protects liquidity and sanctions readiness, what gets delayed? If it accelerates one modernization program by reducing operational fragility, what other initiative costs people’s lives? If a region becomes harder to serve profitably under new risk assumptions, what does that mean for revenue plans, client coverage, and capital allocation? Those are painful questions, but they are far less painful when asked early.

This is why real-time scenario planning matters in wartime conditions. It helps banks move from narrative to arithmetic. From reaction to comparison. From isolated function views to system-level tradeoffs. And from vague resilience language to specific choices made today, this week, not next quarter. That urgency is consistent with what Reuters described as conflict-driven market repricing, elevated oil, and delayed expected Fed cuts.

It matters because the bank that can compare plausible paths quickly has a real advantage over the bank that can only defend last quarter’s assumptions more eloquently.

What the board should conclude now

In practical terms, continuous scenario planning lets leadership test questions that are now central to resilience:

• If energy stays elevated for two more quarters, which sectors deserve immediate credit scrutiny?
• If rates remain higher for longer, which transformation initiatives still deserve capital, and which should be slowed?
• If sanctions widen, which payment corridors become operationally fragile?
• If the same teams are needed for compliance changes, cost reduction, and modernization, where will overload appear first?
• And perhaps most importantly, what does management choose to protect when it cannot protect everything?

That is the heart of the issue. In times of war, the planning challenge is not prediction. It is prioritization under pressure.

If I were making the board-level case for urgency, I would put it this way: banks do not need another quarter of elegant commentary about uncertainty. They need a weekly discipline that shows which assumptions have broken, which exposures have changed, which commitments no longer hold, and which decisions cannot wait. Without that, the institution is not planning. It is narrating.

The institutions that handle this best will not be the ones that guessed the future most precisely. They will be the ones who built a planning discipline capable of absorbing change without freezing. They will recognize that resilience now depends on decision speed, not just capital strength. And they will understand that planning cannot remain an annual ritual in a world where geopolitical shocks are continuous.

War broke that model.

Banks now need one that moves.

This article is published as part of the Foundry Expert Contributor Network.
Want to join?