The infrastructure decision sitting in the wrong room

I spent this weekend at an AI implementation workshop where someone walked through what Rust does and why AI safety researchers care about memory-safe systems. I came home thinking less about Rust itself and more about three signals that seem to be pointing toward the same question.

The first: Anthropic published material in February 2026 on how Claude Code could help automate parts of COBOL modernization — dependency mapping, documentation, workflow discovery. IBM’s shares fell 13.2% that day, their steepest daily decline since October 2000.¹ The market saw a services disruption story. Banks should also see a legacy-infrastructure story.

The second: The OCC’s Spring 2025 Semiannual Risk Perspective continued to flag prolonged use of older systems as a source of operational outages, security vulnerabilities, maintenance challenges, and reduced resilience.² Legacy infrastructure is no longer only a cost or maintenance issue. It is starting to be understood as a constraint on speed, security, and AI deployment.

The third: The G7 Cyber Expert Group published a 2026 roadmap for the financial sector’s transition to post-quantum cryptography — emphasizing that the transition is complex, time-consuming, and requires governance, inventory, dependency management, and coordinated planning across institutions, vendors, infrastructure operators, and public authorities.³

Individually, these look like separate topics: legacy modernization, AI-assisted code analysis, memory safety, post-quantum readiness, operational resilience.

But they are starting to converge into one strategic question: what foundation are we building the next decade of intelligent financial systems on?

TLDR

The infrastructure question converging across banking is broader than “Rust versus C++” or “cloud versus mainframe.” It is about whether the institution has a coherent foundation for secure, auditable, AI-enabled financial systems.

Memory safety, AI modernization, and post-quantum readiness are converging. Treating them as separate programs may create duplicated spend, slower execution, and architectural constraints that show up later as AI deployment limits.

The AI dimension

The cybersecurity concern behind this convergence is not hypothetical. Anthropic has publicly described using Claude Mythos Preview to search for vulnerabilities in open-source ecosystems and closed-source software under appropriate conditions. Its published examples focused heavily on memory safety vulnerabilities, in part because critical systems such as operating systems, browsers, and core utilities are often written in memory-unsafe languages like C and C++.⁴

That does not mean every legacy system is suddenly exposed. It does mean the cost of exploring complex code is falling.

The direction of travel is clear: AI-assisted vulnerability discovery, fuzzing, exploit analysis, and code comprehension are improving. For financial institutions, the relevant question is not whether these tools are good or bad. The question is whether defensive modernization can move faster than automated discovery.

That is where memory-safe languages enter the conversation.

The quantum dimension

Post-quantum readiness is not only about future quantum computers. It is also about “harvest now, decrypt later” risk: encrypted data can be captured today and potentially decrypted later if cryptographically relevant quantum computers emerge.

Central banks are already experimenting. BIS Project Leap Phase 2 tested post-quantum cryptography in payment-system-like settings, including liquidity transfers using post-quantum digital signatures. The BIS noted that significant performance differences between traditional and post-quantum algorithms still require further testing and preparation before broad financial-system transition.⁵

The Hong Kong Monetary Authority has also announced a Quantum Preparedness Index to assess banking-sector readiness for post-quantum cryptography.⁶

The implication: post-quantum readiness will not be solved by swapping one cryptographic library for another at the end of the decade. It requires inventory, architecture, vendor coordination, testing, performance analysis, and governance — work that looks very similar to legacy modernization. Part of why treating them as separate programs may create unnecessary friction.

What Rust is, and whether it is the answer

Rust is a systems programming language designed to deliver high performance with strong memory safety guarantees. Its ownership model helps prevent classes of bugs such as buffer overflows, dangling pointers, and use-after-free errors at compile time.

That matters because memory safety vulnerabilities have been a persistent source of severe software risk. CISA and NSA’s 2025 guidance notes that memory-safe languages such as Ada, C#, Go, Java, Python, Ruby, Rust, and Swift offer built-in protections against memory safety issues and can prevent entire classes of vulnerabilities.⁷

But Rust is not the only answer.

Go is memory-safe through garbage collection and is often more approachable for backend services, APIs, platform tooling, and cloud-native services. Java and Kotlin are practical paths for institutions already invested in the JVM. C# is highly relevant in Microsoft-heavy enterprise environments.

The question is not whether every bank should rewrite everything in Rust.

A better question is: where do we need memory safety, performance, auditability, and long-term maintainability badly enough to change the engineering foundation?

For some domains, Rust may be compelling: latency-sensitive services, cryptographic components, high-throughput risk engines, settlement infrastructure, and security-sensitive systems where performance and memory safety matter together. For many other domains, Go, Java, Kotlin, C#, or managed cloud-native architectures may be the more practical path.

Why C++ safety-in-place is getting harder

Some institutions may hope the answer is simply to keep existing C++ estates and make them safer over time.

That may be possible in parts of the stack, but the path is less certain than it looked a few years ago. In 2025, work on the Safe C++ extensions proposal was discontinued in favor of safety profiles and related tooling efforts. InfoWorld reported that the committee prioritized a more incremental, backward-compatible approach while the Safe C++ proposal did not reach consensus.⁸

For financial institutions, that suggests a portfolio approach:

· Keep and harden where replacement risk is too high.

· Wrap and isolate where interfaces can reduce blast radius.

· Rewrite selectively where the business case, risk profile, and talent model justify it.

· Build new strategic systems on memory-safe foundations by default.

The infrastructure decision is also an AI decision

This is where the conversation becomes bigger than cybersecurity.

Regulated AI in financial services will require traceability, resilience, testing discipline, access controls, model governance, data lineage, auditability, and operational reliability. Those capabilities do not sit only in the model layer. They depend on the infrastructure underneath.

A bank can have strong AI ambition, but if its production architecture cannot support reliable observability, secure integration, cryptographic agility, and controlled deployment, the AI roadmap eventually hits architectural limits.

That is why memory safety and post-quantum readiness may be worth considering not only as defensive programs, but as part of the foundation for trustworthy AI deployment. The institutions making these decisions for security reasons are also making decisions about the speed and shape of their AI transformation — whether they recognize it as such or not.

A simple diagnostic

A practical starting point for any leadership team:

Pull your memory-safety roadmap, your AI infrastructure roadmap, and your post-quantum cryptography roadmap. Are they part of the same strategic planning conversation?

In many institutions, these efforts are governed separately. That is understandable. Security, infrastructure, AI, cryptography, and resilience often sit in different parts of the organization.

But the underlying question is increasingly shared: what foundation are we building the next decade of intelligent financial systems on?

If these are separate line items with separate owners and separate funding cycles, the organization may miss opportunities to coordinate investment, reduce duplication, and build a more resilient foundation.

· Memory-safe modernization reduces structural software risk.

· Post-quantum readiness protects long-term trust in financial data and transactions.

· AI infrastructure enables intelligent systems to be deployed safely, repeatedly, and at scale.

These may not need to be one team. But they should be one leadership conversation.

The question worth asking

Who in the institution is convening that conversation?

In some firms, that may sit with the CIO. In others, the CISO, CTO, Chief Data and Analytics Officer, Chief AI Officer, or a transformation executive may play the convening role. The title matters less than whether the conversation is happening.

The opportunity over the next decade may not come from picking one technology perfectly. It may come from recognizing that AI transformation is also an infrastructure strategy decision — and making sure memory safety, cryptographic readiness, operational resilience, and AI infrastructure are part of the same leadership conversation.

- Shish

References

¹ Reuters, “IBM posts steepest daily drop since 2000 after Anthropic says AI can modernize COBOL,” February 2026. See also: Anthropic, How AI helps break the cost barrier to COBOL modernization, February 2026. anthropic.com

² OCC, Semiannual Risk Perspective, Spring 2025. occ.gov/publications-and-resources/publications/semiannual-risk-perspective

³ G7 Cyber Expert Group, “Advancing a Coordinated Roadmap for the Transition to Post-Quantum Cryptography in the Financial Sector,” January 2026. US Treasury press release, home.treasury.gov.

⁴ Anthropic, Claude Mythos Preview security research documentation, 2026. anthropic.com

⁵ BIS Innovation Hub, Project Leap Phase 2: Quantum-proofing payment systems, December 2025. bis.org

⁶ Hong Kong Monetary Authority, Fintech Promotion Blueprint, February 2026. hkma.gov.hk

⁷ CISA/NSA, “Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development,” June 2025. cisa.gov. See also: White House ONCD, “Back to the Building Blocks: A Path Toward Secure and Measurable Software,” 2024.

⁸ InfoWorld, “Safe C++ proposal for memory safety flames out,” September 2025.