Threat Modeling for Financial Institutions

Threat modeling for financial institutions has traditionally been conducted as a periodic, manual exercise scoped around individual applications. This paper examines whether that model remains defensible given current breach-cost and attack-surface data. Drawing on the IBM/Ponemon Cost of a Data Breach Report (2025), Indusface’s State of Application Security: Banking and Financial Services report (H1 2025), and Black Kite’s 2026 Financial Services Cybersecurity Report, we find that both the financial consequence of failure and the rate of attack-surface growth have outpaced the cadence at which manual threat modeling operates. We then describe risk-based, automated threat modeling, specifically the PASTA (Process for Attack Simulation and Threat Analysis) methodology, as a structural response to this gap, and close by naming where that response is itself incomplete.

Introduction

The case for threat modeling for financial institutions is not usually made with numbers. It is made with the general observation that banking applications are complex, regulated, and attractive targets, and that some structured process should therefore exist before those applications ship. That observation is true but underspecified. It does not explain why a manual, workshop-based version of that process the version most financial institutions still run is failing to keep pace, or what “keeping pace” would even require.

This paper attempts a narrower, more falsifiable version of the argument. Section 2 presents current breach-cost data specific to financial services. Section 3 presents attack-surface growth data specific to banking applications and APIs. Section 4 uses both to argue that manual threat modeling for financial institutions has a structural cadence problem, not merely an execution problem. Section 5 describes the risk-based, automated alternative and the methodology it is built on. Section 6 states the limitations of that alternative plainly, because a paper that only makes the case for a solution without stating where it runs out is not a complete argument.

The Cost of Application Security Failures in Financial Services

The IBM/Ponemon Cost of a Data Breach Report 2025, based on data from 600 organizations across 17 industries, places the global average cost of a breach at $4.44 million, a 9 percent decrease from 2024. Financial services sits at $5.56 million, down from $6.08 million the previous year, but still the second-highest figure of the 17 sectors measured, behind only healthcare.

Two details in the underlying report are relevant to a discussion of threat modeling for financial institutions specifically, rather than data breach cost in general. First, the report attributes a substantial share of the difference between low-cost and high-cost breaches to detection speed: breaches identified and contained within roughly 200 days cost measurably less than those that take longer, with different secondary analyses of the same report placing that gap somewhere between $1.1 million and $1.9 million depending on which benchmark within the report is cited. We flag the inconsistency rather than resolve it, because the more important point survives either figure: detection speed is a cost variable, and detection speed is partly a function of whether an organization already understood, before an incident, which systems and trust boundaries were likely to matter. That is a threat modeling output, not an incident-response output.

Second, the same report finds that organizations using AI and automation extensively in security save an average of $1.9 million per breach relative to organizations using neither while separately finding that unsanctioned “shadow AI” tool use adds roughly $670,000 in cost when it contributes to an incident. Automation, in other words, is not uniformly protective; it is protective when governed and costly when not, a distinction this paper returns to in Section 6.

The Expanding Attack Surface: Banking APIs Under Load

Cost data describes the consequence of failure. It does not describe why the rate of failure might be changing. For that, attack-surface data specific to banking applications is more informative.

Indusface’s State of Application Security: Banking and Financial Services report for the first half of 2025 recorded more than 742 million attacks against financial services web and API applications in a six-month window, a 51 percent increase over the same period in 2024. Within that total, attacks specifically targeting the API layer rose 60 percent, and API-layer DDoS attempts rose 518 percent.

The disparity between the 51–60 percent figures and the 518 percent figure is itself informative, and worth sitting with rather than averaging away. It suggests that attackers are not simply scaling up a uniform approach to financial services applications; they are concentrating disproportionate effort on the API layer specifically, and within that layer, on availability rather than data exfiltration. A threat model built around a generic notion of “attacks against the application” will not surface that concentration. A threat model that decomposes the system into its component trust boundaries, including the API layer as a distinct surface with its own threat profile, has a chance to.

Separately, industry surveys of API security posture Salt Security’s Q1 2025 data among them report that a large majority of organizations experienced at least one API-related security incident in the preceding year, while a small minority report having implemented formal API security governance. That gap between incident frequency and governance maturity is consistent with the cost and attack-growth figures above: the applications and interfaces under the heaviest and fastest-growing attack pressure are, by a wide margin, the least likely to have a governance process that scales with them.

Where Manual Threat Modeling Breaks Down

A manual, workshop-based threat model is bounded by the calendar on which workshops happen and the number of systems a small group of people can review carefully in the time available. Neither of those constraints has changed in the last several years. The attack surface and financial consequence described in Sections 2 and 3 have.

Black Kite’s 2026 Financial Services Cybersecurity Report provides a useful proxy for how quickly the threat landscape itself is moving, independent of application-layer attack volume. Direct ransomware incidents against financial institutions climbed from 156 in 2024 to 202 in 2025, a 30 percent year-over-year increase, reversing a brief decline the year before. Early figures for the first quarter of 2026, 65 incidents, represent a 76 percent increase over the same quarter of 2025, suggesting the 2025 acceleration was not a one-year anomaly.

The same report notes that the vendor ecosystem financial institutions depend on has grown measurably more dangerous over the same period, with the number of vendors carrying critical-severity vulnerabilities in that ecosystem increasing nearly fivefold. This matters for threat modeling for financial institutions specifically because a threat model scoped to an institution’s own application, without accounting for the trust extended to vendors and integrations feeding it, is describing a system that no longer matches how the application actually operates.

None of this data proves that manual threat modeling produces worse individual analyses than automated approaches. A skilled analyst working carefully on a single system can produce a rigorous, defensible threat model by hand. The problem is coverage and cadence: an approach bounded by workshop scheduling and analyst headcount cannot review as many systems, as often, as an attack surface growing at 51 to 518 percent year-over-year requires. That is a structural limit, not a competence gap, and it is the specific reason automated, risk-based approaches to threat modeling for financial institutions have moved from optional to load-bearing for institutions with large application portfolios.

Risk-Based, Automated Threat Modeling as a Structural Response

The methodological response to a coverage-and-cadence problem is not simply “add software.” Automating an inconsistent process produces a faster inconsistent process. The response that has held up under continued use is a consistent, risk-based methodology applied at automated scale, and the most established example of that methodology is PASTA (Process for Attack Simulation and Threat Analysis), a seven-stage framework co-developed by VerSprite founder Tony UcedaVélez and Marco M. Morana and documented in their 2015 book on risk-centric threat modeling.

PASTA’s structural contribution to the coverage problem described in Section 4 is that it fixes the sequence of analysis: business objectives, technical scope, decomposition, threat analysis, vulnerability analysis, attack modeling, risk and impact analysis regardless of which analyst or which automated platform is executing it. That fixed sequence is what makes automation meaningful rather than cosmetic: a platform correlating threat intelligence and vulnerability data against a system’s decomposition (stage four) is doing the same category of work a human analyst would do at that stage, just at a scale and update frequency a workshop cannot sustain. Continuous platforms built on this model, VerSprite’s Fork among them, are designed specifically to keep a system’s threat model current as its APIs, integrations, and infrastructure change, rather than accurate only as of the last scheduled review.

For an institution with dozens or hundreds of applications, that continuity is the practical difference between a threat model that describes the system as it existed at the last review and one that describes the system as it currently exists, which, given the attack-growth figures in Section 3, is not a small difference.

Limitations and Open Questions

This argument has real limits, and stating them is part of making the argument honestly rather than part of undermining it.

First, the cost and attack-growth figures cited in Sections 2 and 3 are correlational with respect to threat modeling practice, not causal. No dataset in this paper measures breach cost or attack volume as a function of whether the affected organization used manual or automated threat modeling. The argument here is that the operating conditions have changed in ways that favor automated, risk-based approaches, not that a specific institution’s manual process caused its specific losses.

Second, automation is not uniformly beneficial, a point the IBM report itself makes when it separates governed AI and automation use (associated with lower breach cost) from ungoverned “shadow AI” use (associated with higher cost). The same distinction almost certainly applies to threat modeling platforms: a platform generating findings without a consistent scoring methodology behind it is likely to produce faster noise rather than faster signal. Section 5’s argument depends on the methodology being sound before the automation is applied to it, and that ordering is easy to get backward under commercial or deadline pressure.

Third, consistency across analysts and across platforms remains an open problem even within a fixed methodology. PASTA’s later stages, particularly risk and impact analysis, require a judgment call about how a given attack path weighs against a defined business objective, and that judgment varies between people even when the underlying framework is identical. Automation can enforce that the same categories of information are considered at each stage; it cannot, by itself, guarantee that two different implementations weigh a given finding the same way.

Fourth, the API-attack and ransomware figures in this paper are drawn from vendor and research-firm reports rather than from a single standardized government or academic dataset, and methodologies differ across sources a limitation common to most current empirical work on this topic, given the absence of a unified public reporting standard for application-layer attacks in financial services.

Conclusion

The case for threat modeling for financial institutions to move away from a purely manual, periodic model does not rest on a claim that manual analysis is unrigorous. It rests on a narrower, more specific claim: that the financial cost of failure, the rate of attack-surface growth, and the pace of change in the vendor ecosystem underlying most banking applications have all moved faster than a workshop-bound review cycle can track. Risk-based, automated approaches built on a fixed methodology such as PASTA address the coverage and cadence problem directly. They do not, on their own, resolve the harder problem of consistent judgment across analysts and systems, and a paper arguing for this shift should say so, rather than implying the harder problem has already been solved.

References

1. IBM Security / Ponemon Institute. Cost of a Data Breach Report 2025. ibm.com/reports/data-breach
2. Indusface. State of Application Security: Banking and Financial Services H1 2025. indusface.com
3. Black Kite. 2026 Financial Services Cybersecurity Report. blackkite.com/reports/2026-financial-services-report
4. Salt Security. State of API Security Report, Q1 2025. https://salt.security/press-releases/salt-labs-state-of-api-security-report-reveals-99-of-respondents-experienced-api-security-issues-in-past-12-months
5. UcedaVélez, T., and Morana, M.M. Risk Centric Threat Modeling: Process for Attack Simulation and Threat Analysis. Wiley, 2015.

Frequently Asked Questions