Fraud teams need revenue metrics, not just loss prevention

At a glance

What this is: This is an analysis of how fraud and trust and safety teams are reframing their value from blocked losses to business outcomes enabled.

Why it matters: It matters because practitioners in identity, fraud, and security increasingly need to translate control performance into metrics leadership already uses for growth, customer experience, and operational cost.

By the numbers:

• The average person now has 200+ apps on their phone, which expands identity-touching entry points and increases the fraud attack surface.

👉 Read Sift’s analysis of how fraud teams can tie prevention work to revenue outcomes

Context

Fraud programmes fail when they are measured only as cost centres, because leadership usually decides on growth, conversion, and customer experience. The article argues that fraud work becomes more defensible when teams show how it supports revenue, not only how much loss it blocks.

That shift is closely related to identity governance because fraud controls depend on how identities, accounts, and sessions are trusted across onboarding, login, and payment flows. When those controls are fragmented, fraud teams inherit the operational cost of broader identity weakness rather than a narrow abuse problem.

Key questions

Q: How should fraud teams prove their value to leadership?

A: They should show how fraud controls affect revenue, customer experience, and operating cost, not just losses blocked. Executive audiences usually fund outcomes they can see in growth or efficiency terms, so the reporting model has to connect fraud decisions to acceptance rates, friction, and protected revenue. That makes the programme easier to defend and easier to prioritise.

Q: Why do fraud and identity teams need shared context?

A: Because fraud decisions depend on whether an identity, account, or session is trusted across multiple touchpoints. Support, product, finance, and security each hold part of that picture, so isolated fraud review leads to slower decisions and inconsistent outcomes. Shared context turns fraud from a single-team queue into a coordinated trust decision.

Q: What do organisations get wrong about fraud metrics?

A: They often report only blocks, chargebacks, and losses prevented, which tells leadership what was stopped but not what was enabled. That misses acceptance, customer friction, and the operational effort required to run the programme. Strong fraud governance measures both risk reduction and the business value preserved by accurate approvals.

Q: Who should own fraud outcomes inside the business?

A: Fraud ownership should sit with the team that can coordinate decisions across support, product, payments, finance, and security. The reporting line matters less than whether the programme has enough cross-functional authority to share signals and reduce friction. A mature fraud model behaves like a trust function, not a siloed review desk.

Technical breakdown

Why fraud metrics break down when they ignore revenue

Fraud operations often measure what they can block, such as chargebacks, account takeover, and policy abuse, but those metrics do not tell executives how the business is performing. A fraud system can reduce losses while also creating too much friction for legitimate customers, which depresses acceptance rates and damages conversion. The core problem is that fraud is connected to value exchange, so the control surface is not only defensive. It is also commercial, which means measurement has to include both risk reduction and business enablement.

Practical implication: align fraud reporting to acceptance, friction, and revenue outcomes, not only blocks and losses.

How cross-functional signal sharing changes fraud governance

The article's strongest governance point is that fraud teams cannot operate as an isolated function. Shared signals from support, product, finance, and growth help fraud teams place suspicious behaviour in context, while fraud intelligence can reduce downstream workload for those same teams. This is a data governance issue as much as an operating model issue, because the value comes from combining signals that normally sit in separate systems and ownership chains. Without that integration, each team optimises locally and the business loses the joint outcome.

Practical implication: build shared signal flows and joint OKRs so fraud controls support other business teams rather than slowing them down.

The first-team model as a control architecture

The 'first team' concept is more than a cultural idea. It is a control architecture for fraud programmes that need support from customer success, sales, product, security, and finance. If those teams share context, fraud decisions become faster, less repetitive, and easier to defend. Where the model matters most is in identity-heavy workflows, because account recovery, onboarding, and payment verification often depend on cross-team context. That makes fraud governance similar to identity governance: the control only works when the operational owners agree on the decision boundaries.

Practical implication: treat fraud as a cross-functional decision system, not a standalone review queue.

Threat narrative

Attacker objective: The objective is to exploit trust and conversion paths while preserving the appearance of legitimate customer behaviour.

1. Entry occurs through high-volume digital touchpoints where a user can look legitimate at first contact, especially across mobile apps, payment flows, and account creation.
2. Escalation happens when suspicious behaviour blends into normal customer activity and teams lack shared context, allowing abuse, account takeover, or policy misuse to continue.
3. Impact is measured not only in losses, but in reduced acceptance rates, higher friction, and misallocated budget when fraud is treated as a back-office cost rather than a growth control.

NHI Mgmt Group analysis

Fraud governance is becoming identity governance by another name. The article shows that fraud teams are now expected to manage trust decisions across onboarding, login, payment, and customer support. Those are identity questions, not just fraud questions, because every approval and rejection depends on how a person or account is verified in context. Practitioners should stop treating fraud as a separate metric silo and start governing it as part of the identity decision chain.

The named concept here is revenue-linked fraud governance. That means fraud controls are judged by whether they protect growth without creating unnecessary friction, not by loss prevention alone. This is where identity programmes and fraud teams overlap most strongly: both are trying to preserve legitimate access while rejecting abuse. The practical conclusion is that leaders should measure control effectiveness against business outcomes and customer trust together.

Cross-functional signal sharing is now a core control, not an organisational nice-to-have. The article’s first-team model reflects a wider shift in security governance toward shared operational context. When support, product, finance, and fraud operate from different data and incentives, the business pays for duplicated effort and slower decisions. Practitioners should build shared decision pathways so trust signals can be reused across teams rather than trapped in one function.

The business case for fraud has to be written in the language of operating models. Leadership will keep rewarding teams that show how they enable conversion, expansion, and customer experience. That is not a marketing problem, it is a governance problem, because controls that cannot be tied to business outcomes will be underfunded. For practitioners, the implication is to redesign reporting so fraud capability is visible as a contributor to revenue protection and customer retention.

What this signals

Revenue-linked fraud governance will become a more common operating model as executives demand clearer evidence of how trust controls support growth. Teams that can connect fraud prevention to conversion, customer experience, and operational efficiency will have a stronger case for investment than teams that report losses alone.

Identity programmes should take note because fraud is increasingly a downstream signal of identity assurance quality. If onboarding, recovery, and session trust are weak, fraud teams end up compensating for failures that belong in the identity control stack, not just in the fraud rules engine.

The next maturity step is not more alerts, but better decision reuse across support, payments, and risk. That means mapping trust signals to CISA cyber threat advisories where relevant and aligning identity decisions to the control intent behind NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Reframe fraud reporting in business terms Translate one core fraud metric into revenue, conversion, or customer experience language before the next executive review. Use the same incident data, but express it as protected revenue or preserved legitimate approvals rather than only blocked losses.
• Create a shared signal model with adjacent teams Work with support, payments, product, and finance to share the identity and behaviour signals that influence approval decisions. The goal is to reduce duplicated reviews and make fraud context available where customer friction is already being handled.
• Tie fraud controls to joint OKRs Set at least one joint objective with another business function so fraud success contributes to a second team’s outcome, such as turnaround time or conversion. Shared goals make it easier to justify resources when budgets are reviewed.
• Update executive summaries for leadership audiences Replace internal fraud jargon with a short summary that shows how the programme protects growth, reduces waste, and improves customer experience. Keep the operational detail in the appendix and put the business case first.

Key takeaways

• Fraud teams are being judged on business value enabled, not only loss prevented.
• Shared context across support, product, finance, and security is now a control issue, not just an operating preference.
• Identity governance and fraud governance are converging because both depend on trust decisions at the point of access or approval.

Key terms

• Real-Time Fraud Decisioning: Real-time fraud decisioning is the practice of evaluating a payment or account action before it completes, using identity, behavioural, and transaction signals. In fast-moving P2P systems, it is the difference between preventing abuse and only documenting it after funds have moved.
• Acceptance Rate: Acceptance rate is the proportion of legitimate transactions or users that are approved by the control process. In fraud programmes it is a key operating metric because overly aggressive controls can reduce revenue and damage customer experience even when losses fall.
• Cross-Functional Signal Sharing: Cross-functional signal sharing is the controlled exchange of relevant risk and identity data between teams such as fraud, support, product, finance, and security. It improves decision quality by giving each team more context, but it also requires clear ownership, data boundaries, and governance.

What's in the full article

Sift's full article covers the operational detail this post intentionally leaves for the source:

• The specific cross-functional OKR examples that show how fraud teams can align with growth, support, and finance.
• The session discussion points behind the revenue-table framing, including the language executives are most likely to respond to.
• The practical ways fraud leaders can translate loss prevention into protected revenue and reduced customer friction.
• The audience polling detail on where fraud should sit organisationally and why reporting line matters less than rapport.

👉 The full Sift session covers the cross-functional model, executive framing, and practical metric changes in more detail.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and identity lifecycle fundamentals. It is suitable for practitioners who need to connect trust controls to broader security and business outcomes.