Security and fraud risk: one threat, two teams

What is security and fraud risk?

Security and fraud risk is the chance that a weakness in your software lets an attacker commit fraud against you or your customers. It joins two fields that usually live apart: application security, which finds and fixes software flaws, and fraud prevention, which detects and stops financial abuse.

The Association of Certified Fraud Examiners (ACFE) explains fraud with the fraud triangle, a model from the criminologist Donald Cressey. It has three parts: an "unshareable financial need," a "perceived opportunity" and a "rationalization." Cressey studied embezzlers, people who steal money that others trust them to manage, so the fraud triangle describes internal fraud first.

External fraud is fraud that people outside the company commit, such as customers, impostors or criminal groups. For external fraud against a digital business, the opportunity side of the fraud triangle is often a software flaw: a password reset that does not check identity, an API that returns another customer's data, a payment form that accepts any amount. The fraud team cannot remove that opportunity. Only the people who write the code can. That is cyber fraud risk in one sentence: the motive belongs to the attacker, but the opportunity belongs to your software.

The opportunity side of the fraud triangle, seen from the application. Own work. 

Why do fraud programs leave engineering out?

The fraud guidance we reviewed asks several teams to work together, but none of it names the team that writes the code. The US Office of the Comptroller of the Currency (OCC) says in Bulletin 2019-37 that "Fraud risk is a form of operational risk." It expects banks to have models, monitoring systems or reports that detect fraudulent activity "across all lines of business and functions."

Fraud risk management guides make the same request. Stripe's guide to fraud risk management asks companies to "engage with stakeholders across various departments" during a fraud risk assessment, the review of where and how fraud can happen in an organization. The guide never mentions engineers or application security.

The two teams also speak different languages. In an October 2025 article, Mastercard wrote that "Cybersecurity and fraud teams use different vocabularies, which contributes to communication challenges." The article also cites a survey in which 60% of global fraud and risk executives say that they learn about cyber breaches only after fraud losses start.

Fraud detection can work without engineering. Closing the flaw that the fraud runs through cannot: no engineering required, no fix either.

Which vulnerabilities enable fraud?

We group fraud that starts in an application into four outcomes: account takeover, data harvesting, payment fraud and fake accounts. Each one has a name on the fraud team's side and a different name on the engineering side. The table uses weaknesses from the Fluid Attacks Database and public cases from regulators.

Card testing fraud is a clear example of the gap. In card testing fraud, attackers run many small payments to learn which stolen card numbers work. Stripe's documentation tells merchants who are not developers, or who use a plugin or platform, that preventing it "typically requires code-level changes." Our post on securing online payment systems covers other flaws in payment flows.

Weakness 417, Account Takeover, in the Fluid Attacks Database.

What does account takeover look like in our research?

Our security researchers find account takeover paths in real applications and publish them as advisories. In Bhima 1.27.0 (CVE-2023-0944), an insecure direct object reference (IDOR), a flaw that lets a user reach another user’s data by changing an ID, let a regular user change other users’ credentials, including the administrator’s.

In VitalPBX 3.2.3-8 (CVE-2023-0486), a reflected cross-site scripting (XSS) flaw let an attacker capture an administrator’s session cookie through a malicious link. In CandidATS 3.0.0 (CVE-2022-42750), a stored XSS flaw, caused by uploaded files that the application did not validate properly, let a remote attacker take over user accounts.

None of these flaws looks like fraud in a scanner report. Each one looks like fraud the day an attacker uses it.

How does fraud risk change as a business scales?

Fraud risk grows faster than the business, because each new feature adds a path that attackers can test. As a business scales, it adds apps, APIs, payment methods and partners. Each release changes the code that the fraud team never sees.

Attackers also automate. The Open Worldwide Application Security Project (OWASP) lists 21 automated threats, such as credential stuffing (OAT-008), defined as "Mass log in attempts used to verify the validity of stolen username/password pairs." Gartner predicts that by 2027, AI agents will cut the time it takes to exploit account exposures by 50%.

The losses are measurable. The FBI Internet Crime Complaint Center (IC3) counts, in its 2025 IC3 Annual Report, about 4,700 account takeover complaints with $359.7 million in losses. In Latin America and the Caribbean, the 2026 DBIR executive summary puts the exploitation of vulnerabilities at 44% of breaches and credential abuse at 5%. Cyber fraud risk, then, is not fixed. It moves with every release, as a business scales.

Credential stuffing (OAT-008). Source: OWASP, CC BY-SA 4.0

Vulnerabilities that count as fraud risk

Not every vulnerability is fraud risk, and a fraud team does not need your full backlog. To assess fraud risk from security vulnerabilities, we use these conditions in our Fraud risk center. A vulnerability counts only when it meets all five conditions:

1. It maps to at least one fraud outcome: account takeover, data harvesting, payment fraud or fake accounts.

2. It is open and not marked as zero risk.

3. It is reachable from the internet.

4. It affects confidentiality or integrity.

5. It shows evidence of real-world exploitation: its exploitation has been observed, not only proven possible.

The result is a short list of what an attacker could use for fraud. Each fraud category then takes the exposure level of its most severe open vulnerability, on a scale of Critical, High, Medium, Low and None. The most exposed category appears first.

The filter changes what the fraud team reads, not what engineering fixes. It turns security and fraud risk into a list that both teams can read. Vulnerabilities that do not meet the five conditions stay reported and managed in the platform as usual. All four categories always appear, even with no exposure, because for a chief information security officer (CISO) who reports to the board, "no exposure" is also an answer. This is how organizations can assess fraud risk with security data and change defenses where the exposure is highest.

Fraud categories sorted by exposure in the Fraud risk center.

How should a fraud team hand a risk to engineering?

A good handoff gives engineering enough context to act without a meeting. A fraud analyst who sees a High exposure in account takeover needs one action: ask the owners of the affected system to fix it first.

In the Fraud risk center, that action is called Escalate. The analyst can escalate one system or all affected systems in a category, and add up to 1,000 characters of context. The system's responsible contacts receive an email with the exposure level, the number of vulnerabilities, up to 10 vulnerable locations and a link to the vulnerabilities in the platform. The system then shows a Requested tag, so other analysts know that the request is already in motion.

The escalation does not change the vulnerability, and the fraud analyst does not see the code. Each team keeps its own work. The fraud team decides what is urgent from a fraud point of view; engineering gets the evidence to fix it. Details are in the Fraud risk center documentation.

Escalating a fraud category to the owners of the affected systems. Own work.

Fraud prevention strategies that need engineering

Fraud prevention strategies built on detection rely on scoring, rules and behavior analytics. These steps add the engineering side, and a team can start each one this quarter.

1. Agree on one vocabulary

Map each fraud outcome to the weaknesses that enable it, as in the table above. Write the map down and share it with both teams. When fraud says "account takeover," engineering should know that it means flaws in authentication, sessions and password reset. When engineering says ‘business information leak,’ fraud should know that it can mean data harvesting.

Keep the map short: four outcomes and ten or eleven weaknesses that matter most in your applications. A long glossary that nobody reads does not close the vocabulary gap.

2. Put engineering in the fraud risk assessment

Add an application security engineer and a tech lead to the next fraud risk assessment. Ask them which systems handle logins, payments, sign-ups and customer data, and which of those are reachable from the internet. That list is where fraud and security vulnerabilities meet. Then ask the fraud team which of those systems already show signs of abuse, such as card testing bursts or new accounts that never transact. A system on both lists goes to the top of the remediation plan.

3. Measure exposure, not counts

A count of 35 open High vulnerabilities says little to a fraud team. The highest open severity in each fraud category says more, because one critical flaw in a payment flow matters more than ten low ones elsewhere. Report exposure by category, and review it after each release. For leadership, the same view answers a simple question: which kind of fraud is our software most exposed to today? That is how security and fraud risk becomes a line in a board report instead of two separate reports.

4. Make escalation a routine

Agree on who receives a fraud escalation, what context it carries and how fast engineering answers. Track how long escalated vulnerabilities stay open, and compare that time with the time for other vulnerabilities of the same severity. If escalated items do not close faster, the routine is not working. Review the numbers with both teams once a month, in the same meeting. Then retest each fix: a reattack confirms that the opportunity is closed, not only that a ticket was closed.

One risk, one conversation

Fraud teams know where the money goes. Engineering knows where the code fails. Neither silo sees the flaw that connects the two. Security and fraud risk drops when both teams look at the same short list and act on it in the same week. We built the Fraud risk center for that conversation: it shows fraud teams which flaws enable fraud and sends engineering the evidence to fix them.

FAQ

What is the difference between credential stuffing and account takeover?

Credential stuffing is one way to take over accounts. Attackers try stolen username and password pairs on a login page at scale, and OWASP lists it as automated threat OAT-008. Account takeover is the result: the attacker controls a real customer's account. Other paths lead to the same result, such as session theft or a weak password reset. Our guide to credential stuffing explains the attack in detail.

Do fraud detection tools find application vulnerabilities?

No. Fraud detection tools analyze transactions, devices and behavior to stop abuse while it happens. They do not read source code or test an application for flaws. Security testing, such as static analysis, dynamic analysis and penetration testing, finds the vulnerabilities. The two kinds of tools answer different questions, which is why the teams that use them need a shared view.

Does PCI DSS require controls on payment page scripts?

Yes. The PCI Security Standards Council explains that Requirements 6.4.3 and 11.6.1 of the Payment Card Industry Data Security Standard (PCI DSS) v4.x aim to make sure that payment page scripts are "properly authorized, checked for integrity, and monitored for tampering." The council also warns that scripts in consumers' browsers "are now a significant target for attackers seeking to steal payment card data."

Is all digital fraud caused by software vulnerabilities?

No. Much of the fraud that people report starts with social engineering, such as fake calls, phishing and investment scams, with no software flaw involved. In the 2025 IC3 Annual Report, investment fraud caused the largest reported losses. Security and fraud risk covers the part of fraud that depends on a weakness in your applications. That part is the one engineering can remove.