Why Static Analysis Just Became a Boardroom Conversation in Fintech

\ On February 23, 2026, IBM lost roughly $31 billion in market value in a single trading session. It was the company's steepest one-day drop since the dot-com crash, and the trigger wasn't an earnings miss or a product recall. It was a blog post. Anthropic had published research arguing that its Claude Code tool could automate the hardest part of modernizing COBOL systems, the months of dependency mapping, workflow tracing, and risk flagging that consulting firms had spent decades charging banks for. Analysts are still arguing about whether the market overreacted. What isn't really in dispute is what the reaction revealed. Reading legacy code and figuring out what it actually does, before anyone dares touch it, used to be a back-office IT function. Now it's apparently a line item that moves stock prices. For an industry that runs an estimated 95% of U.S. ATM transactions through COBOL written before most of its current engineers were born, that's a strange and frankly overdue kind of validation. Static analysis, the practice of scanning source code for defects, vulnerabilities, and structural risk without ever running it, has quietly become one of the more consequential categories in software right now. Fintech is at the center of why. A Tool Nobody Used to Notice For most of its history, static analysis lived in the background. It was the linter that flagged a missing semicolon. The SAST scanner bolted onto a CI pipeline mostly to satisfy a compliance checkbox. Developers tolerated it. Few people outside an engineering org thought about it at all. That's changed, and not really for reasons that have much to do with code quality in the traditional sense. A shrinking share of code is being read by a human before it ships. AI coding assistants now generate a meaningful fraction of commits across enterprise codebases, and that share climbs every quarter. Code that used to pass through a developer's mental model on its way from idea to keystroke sometimes arrives fully formed now: plausible-looking, mostly correct, and occasionally wrong in ways a human author probably wouldn't have been. Security teams describe this less as a quality problem than a triage problem. There are simply more candidate defects than humans can review one at a time. Regulators stopped treating software resilience as optional. The EU's Digital Operational Resilience Act entered into force in January 2025 and is moving into a stricter supervisory phase through 2026. It requires banks, insurers, and fintechs to run continuous digital resilience testing programs and to extend that scrutiny across their software supply chains, not just their production environments. There's no carve-out for AI-assisted development, either. Generative tools used anywhere in a financial software pipeline get folded into the same ICT governance and testing obligations as everything else. For a compliance officer, that turns static analysis from a nice-to-have into documented evidence. And then there's the legacy estate itself. COBOL alone is estimated to underpin several trillion dollars' worth of financial infrastructure worldwide, maintained by a workforce that's retiring faster than it's being replaced. Before any modernization project can begin, someone has to answer a deceptively hard question: what does this thirty-year-old batch job actually do, end to end, across the dozens of copybooks and nested call chains nobody fully documented along the way? That discovery work used to be a multi-year, multi-million-dollar consulting engagement. It's exactly the terrain static analysis platforms are now being asked to cover at scale. How the Tooling Is Actually Changing The market numbers reflect the shift, though not dramatically. Forecasts put the static code analysis software market somewhere between $1.1 and $1.4 billion in 2026, growing at a modest single-digit to high-single-digit CAGR depending on whose model you trust. That's not hypergrowth. What's more interesting than the topline number is what's happening inside the category. The biggest fault line sits between tools that stayed deterministic and tools that added genuine contextual understanding. Traditional static analysis works off pattern matching against known rule sets: fast and explainable, but blind to anything that requires understanding what a piece of code is actually trying to do. A newer generation of tools layers AI on top of that foundation to reason about data flow, business logic, and intent rather than syntax alone. The distinction matters because rule-based tools can only catch what someone already wrote a rule for. A logic error or an architectural anti-pattern can sail straight through. The less glamorous battle is over noise. Industry surveys keep putting the false-positive problem at the center of why static analysis tools get ignored. Nearly half of organizations cite high false-positive rates as their biggest adoption barrier, and some benchmarks show several false alarms for every thousand lines scanned. A scanner that buries one real vulnerability under a hundred irrelevant warnings teaches developers to stop reading the output entirely. The procurement conversation has shifted accordingly. Buyers increasingly ask not how many rules a tool has, but how many of its findings hold up against independent benchmarks like the OpenSSF's, and whether it ships an actionable fix alongside the warning instead of just a flag. There's also a quieter shift happening at the foundational layer. A wave of Rust-built linters has made the cheapest tier of static analysis (the kind that runs on every keystroke or every pull request) fast enough that skipping it is no longer a defensible engineering tradeoff. That speed gain doesn't replace the deeper, AI-assisted platforms. It just means teams now layer multiple tools instead of picking one and calling it done. For fintech specifically, the more consequential trend is the rise of platforms built to understand legacy languages with the same rigor modern tooling applies to Java or TypeScript. COBOL, PL/I, JCL, and mainframe Assembler used to be an afterthought for static analysis vendors. That's changing. Platforms are building dedicated metadata repositories that trace control flow and data lineage across thousands of interconnected COBOL programs, which is the same discovery work Anthropic's COBOL announcement put in the spotlight, just approached from the established legacy-tooling side of the market rather than the AI-coding side. The Underrated Static Analysis Platforms Worth Knowing Most "best static analysis tools" roundups published this year circle back to the same five or six names, the ones with the marketing budgets and the OWASP benchmark press releases. That's not wrong, exactly. It's just incomplete for fintech specifically, where the actual bottleneck usually isn't "find more SQL injection bugs in a web app." It's understanding a thirty-year-old COBOL estate, certifying firmware on a payment terminal, or figuring out which hundred of a thousand internal applications to modernize first. A different, much less talked-about layer of the market is built for exactly that. Here's a closer look at four platforms that rarely make the popular lists but solve problems the popular lists don't really cover. | Tool | Core focus | Languages / scope | Standout capability | Best fit | Watch-out | |----|----|----|----|----|----| | SMART TS XL | Legacy & mainframe discovery | COBOL, PL/I, JCL, embedded SQL across z/OS, Unix, Linux, Windows | Centralized metadata repository mapping control flow, data flow, and inter-program dependencies across an entire legacy estate | Banks documenting COBOL/mainframe systems before modernization or regulatory audits | Purpose-built for legacy languages, not a fit for a modern web stack | | GrammaTech CodeSonar | Embedded & safety-critical analysis | C, C++, C#, Java | Certified against ISO 26262, IEC 61508, and EN 50128; can analyze binary-only libraries most scanners skip entirely | Teams building ATM, POS, or payment-hardware firmware | Enterprise pricing and a real learning curve | | PVS-Studio | Deep diagnostic SAST | C, C++, C#, Java (JS/TS in active development) | A dedicated "legacy code" mode that suppresses noise on old code while strictly enforcing checks on everything new | Teams maintaining long-lived C++/C#/Java financial systems | Smaller community than the household-name SAST tools | | CAST Highlight / CAST Imaging | Portfolio-level software intelligence | 60+ technologies, including COBOL and ABAP | Separates "good" technical debt from "bad" technical debt across hundreds of applications at once | CIOs and architects sequencing a multi-year modernization roadmap | Strategic-altitude tooling, pair it with a commit-level scanner rather than expecting it to replace one | SMART TS XL: mapping the codebase nobody fully diagrammed SMART TS XL , from IN-COM Data Systems, is about as close as this list gets to a direct answer to the IBM-COBOL story that opened this piece. It performs static analysis on COBOL, PL/I, JCL, and other mainframe languages without executing the code, parsing IBM and Micro Focus COBOL dialects, nested copybooks, and embedded SQL into a centralized metadata repository. From there it visualizes control flow and inter-program dependencies, traces how data moves from an input field to a final report, maps call chains across hundreds of interconnected programs, and flags dead code and obsolete modules nobody's touched in a decade. That's basically what the "reverse engineering tax" referenced earlier looks like in practice: the months of manual dependency mapping a modernization project burns through before anyone writes a line of new code. To make that concrete, here's the kind of finding this style of analysis is built to surface, illustrated against a small, simplified mainframe program: cobol IDENTIFICATION DIVISION. PROGRAM-ID. ACCT-INTEREST. DATA DIVISION. WORKING-STORAGE SECTION. 01 WS-ACCT-BALANCE PIC 9(9)V99. 01 WS-INTEREST-RATE PIC 9(2)V99. 01 WS-LEGACY-FLAG PIC X(01). 01 WS-AUDIT-CODE PIC X(05). PROCEDURE DIVISION. MAIN-LOGIC. PERFORM CALC-INTEREST PERFORM WRITE-STATEMENT STOP RUN. CALC-INTEREST. COMPUTE WS-ACCT-BALANCE = WS-ACCT-BALANCE * (1 + WS-INTEREST-RATE / 100). LEGACY-OVERRIDE-CHECK. * Flagged: unreachable paragraph, no PERFORM or GO TO * references it anywhere in the call chain. WS-AUDIT-CODE * is written here but never read downstream. MOVE "Y" TO WS-LEGACY-FLAG MOVE "AC001" TO WS-AUDIT-CODE. A static analysis pass like this isn't checking whether the program compiles. It's building the dependency graph that tells a modernization team LEGACY-OVERRIDE-CHECK is dead code, that WS-AUDIT-CODE is a write with no corresponding read, and that the real interest calculation logic lives entirely inside one paragraph that any rewrite has to preserve exactly. Multiply that across a few thousand programs and the value of having it mapped automatically, rather than reconstructed by a room full of consultants reading printouts, becomes obvious fairly quickly. For an institution that needs an audit-ready map of what its mainframe actually does, whether for a DORA-style ICT risk assessment or a modernization business case, this is more directly relevant than almost anything on a typical SAST shortlist. It just doesn't show up on those lists because it isn't trying to compete in that category. GrammaTech CodeSonar: the embedded layer banks rarely talk about GrammaTech CodeSonar covers the part of fintech infrastructure that static analysis conversations usually skip entirely: the embedded layer. ATMs, point-of-sale terminals, and hardware security modules run on C and C++ firmware, and a missed buffer overrun there isn't a CVE sitting in a backlog. It's a physical device in the field. CodeSonar has been certified against ISO 26262, IEC 61508, and EN 50128, supports MISRA and AUTOSAR coding standards, and can extend analysis into binary-only third-party libraries that most source-level scanners simply ignore. It's not a tool a backend web team would reach for, and it's priced and supported like the enterprise embedded-systems product it is. But for the physical edge of the payments network, it's doing work nothing on a typical "top SAST tools" list even attempts. PVS-Studio: a ratchet for fifteen-year-old code PVS-Studio is the one most likely to get written off as "just another C++ linter," which undersells what it's actually built to do. It runs data flow analysis, symbolic execution, taint analysis, and both interprocedural and intermodular analysis across more than a thousand diagnostic rules mapped to CWE, OWASP ASVS, and SEI CERT standards. The detail that matters most for a fintech audience is its legacy code mode. Point it at a fifteen-year-old trading engine, suppress warnings on everything that already exists, and enforce a strict bar only on new commits going forward: yaml # pvs-studio-legacy-mode.cfg (illustrative) exclude-paths: - src/legacy/trading-engine/** rules: legacy-paths: warn-only # existing findings logged, not blocking new-or-modified-files: fail-on-high # strict bar for anything touched after baseline date baseline-date: 2025-01-01 That's a realistic adoption path for a bank that can't justify a multi-quarter remediation sprint but can insist nothing new gets merged without clearing the bar. A ratchet, not a rewrite. CAST Highlight and CAST Imaging: choosing which hundred applications to fix first CAST Highlight and CAST Imaging answer a question that sits one level above what most static analysis tools even attempt. A large financial institution's real problem usually isn't "is this one file clean." It's closer to "which hundred of our thousand applications do we modernize first, with what budget, and at what risk." CAST scans across 60-plus technologies, including COBOL and ABAP, and its Portfolio Advisor for Technical Debt separates debt that's safe to leave alone from debt sitting in business-critical applications that's actively dangerous to ignore. CAST Imaging then lets architects drop into an individual application and see its internal call structure for impact analysis before anyone touches it. It won't gate a pull request the way a commit-level scanner does, and it isn't trying to. It's built for the CIO conversation that happens before the engineering conversation starts. None of these four will top a generic "Best SAST Tools 2026" search result, because none of them are optimized to win that particular content war. What they map onto, closely, are the three forces driving demand described earlier: legacy estate discovery, compliance-grade certainty at the hardware edge, and portfolio-level prioritization across a sprawling application estate. A team securing a five-year-old web app and a bank triaging a thousand-application portfolio that includes COBOL written in 1994 aren't solving the same problem. The right tool usually has less to do with brand recognition than with which of those two problems is actually sitting on your desk. What This Actually Means for a Team Choosing Tools The practical advice converging across the industry right now is fairly consistent, even when the marketing language around it isn't. Layer, don't replace. Fast deterministic linters at the commit level, deeper AI-context-aware scanning at the pull-request level, and dedicated legacy-language analysis for anything touching the mainframe estate function as three separate jobs, not one tool trying to do all three adequately. In practice that might look like PVS-Studio's legacy mode enforcing a bar on new commits, SMART TS XL mapping the mainframe estate sitting next to it, and CAST Highlight rolling both up into a portfolio view a CIO can actually act on. Three different altitudes, not one tool covering all of them. Treat false-positive rate as a procurement metric, not an afterthought. A tool that surfaces two hundred real issues is worth more than one that surfaces a thousand and trains your team to ignore the dashboard. For regulated institutions, make sure the tool's output is something a compliance program can actually point to. DORA's testing requirements reward documented, repeatable evidence of resilience testing. A screenshot of a clean scan doesn't satisfy an auditor the way a continuous, logged static analysis program does. For anyone sitting on a COBOL or mainframe estate, the discovery phase no longer has to take eighteen months and a room full of consultants before a single line of modernization work begins. Whether that's reassuring or unsettling probably depends on which side of the IBM stock chart you were standing on in February. A simplified version of that layered pipeline, just to make the "three altitudes" idea concrete, might look something like this in a CI configuration: yaml stages: - fast-lint # Rust-based linter, runs on every commit, seconds not minutes - deep-sast # AI-context-aware scanner, runs on pull requests - legacy-discovery # mainframe/COBOL static analysis, runs on a schedule, not per-commit fast-lint: stage: fast-lint script: ruff check . --output-format=github deep-sast: stage: deep-sast script: pvs-studio-analyzer analyze -- new-or-modified-only rules: - if: $CI_PIPELINE_SOURCE == "merge_request_event" legacy-discovery: stage: legacy-discovery script: smart-ts-xl scan --target mainframe-estate --report dependency-map.xml rules: - if: $CI_PIPELINE_SOURCE == "schedule" None of this is a real, copy-pasteable pipeline for any specific vendor. It's a sketch of the shape teams are converging on: cheap checks on every commit, deeper analysis at the pull-request gate, and legacy-estate discovery running on its own cadence rather than blocking anyone's afternoon. The Irony Underneath All of This There's a tidy symmetry to where this leaves the industry. The same AI capability that spooked IBM's shareholders, the ability to read decades of undocumented legacy logic and explain what it does, is structurally a static analysis problem. The tools getting built to satisfy bank compliance teams and the tools threatening to disrupt mainframe consulting revenue are converging on the same technical ground: understanding code without running it, at a scale no human team can match manually. Static analysis spent twenty years as the tool nobody in the room cared about. In fintech right now, it's closer to the thing deciding who gets to touch the bank's core systems next, whether that's a human consulting team, an AI agent, or some negotiated mix of both. That's a strange promotion for a category of software most people still associate with squiggly red underlines in their IDE.