What are the signs that fraud and security teams are not operating as one risk function?

What organisational signals show fraud and security are still separate?

When fraud and security operate as one risk function, the organisation applies a shared view of identity, access, transaction behaviour, and escalation. When they do not, the split usually shows up in different ownership models, different evidence standards, and different decisions about what is urgent. That gap matters because attackers, fraud rings, and abuse cases often move across the boundary between account security and financial or operational harm.

Teams frequently discover the divide through operational symptoms rather than strategy documents, and the most obvious clue is that the same event is judged differently depending on which team receives it. The NIST Cybersecurity Framework 2.0 is useful here because it frames governance, detection, response, and recovery as connected functions rather than isolated workflows.

In practice, many organisations only recognise the split after duplicated triage, conflicting case outcomes, or delayed escalation has already allowed the same abuse pattern to recur.

How the split appears in day-to-day operations

The clearest sign of separation is not simply that two teams exist, but that they work from different risk signals and different operating rhythms. Security may focus on compromise indicators such as unusual login behaviour, device trust, session risk, or policy violations, while fraud may focus on monetisation signals such as payment abuse, synthetic accounts, first-party abuse, mule activity, or chargeback patterns. Those views are both valid, but if they are not combined, the organisation sees fragments instead of a single abuse picture.

That fragmentation shows up in several practical ways:

• Cases are opened twice, once as a security incident and once as a fraud event, with no shared owner or shared outcome.
• One team blocks an account while the other allows it back in because the approval path and evidence threshold differ.
• Risk scoring is inconsistent, so the same person or transaction can be low risk in one system and high risk in another.
• Controls are placed at the wrong point in the journey, creating friction for legitimate users while leaving high-value abuse paths underprotected.

The operational test is whether the organisation can connect identity signals, access signals, and abuse signals into a single decision loop. If investigators cannot see the same history, or if analysts cannot explain why one team’s decision should stand over the other’s, the function is not unified. NIST SP 800-53 Rev 5 Security and Privacy Controls is relevant here because it treats control design, monitoring, response, and accountability as part of one security governance structure rather than separate silos.

In practice, the split breaks down most obviously when a fraud pattern is treated as a customer-service issue or a security compromise is handled without considering financial abuse and recovery.

Where the boundary becomes a real governance problem

Tighter fraud controls often increase friction, so organisations have to balance loss prevention against user experience, customer trust, and operational load. The challenge is not that fraud and security teams have different priorities, but that those priorities need a shared escalation rule set when a case crosses both domains.

The boundary becomes a governance problem when teams optimise for their own metrics without a shared risk model. Fraud teams may be measured on loss reduction and case closure speed, while security teams may be measured on compromise containment, alert fidelity, or mean time to respond. If those metrics are not aligned, each team can appear effective while the organisation as a whole remains exposed. The result is often a mismatch between what gets investigated, what gets blocked, and what gets learned.

Common edge cases include:

• Account takeover that starts as a fraud issue but reveals broader credential compromise.
• Abuse of trusted workflows, where the financial harm is obvious before the security compromise is.
• Legitimate but high-risk behaviour, where a security control fires but fraud context would show it should be handled differently.

Where guidance differs by industry, the consensus is that shared governance works better than parallel escalation, but the exact operating model depends on regulatory exposure, customer harm profile, and how much identity intelligence can be shared across teams. The NIST Cybersecurity Framework 2.0 helps most when the organisation needs a common language for governance and response, but it does not replace business-specific fraud decisioning.

Practitioner Guidance

What to prioritise: Build one cross-functional decision path for cases that affect both compromise and abuse, rather than trying to harmonise every workflow at once. The most useful first milestone is shared triage logic for the highest-volume overlap scenarios, because that is where duplicated effort and inconsistent outcomes usually surface first.

What to verify: Confirm that investigators can see the same identity history, event chronology, and case disposition before they make a final decision. If two teams retain separate views of the user, device, session, or payment context, the organisation will keep reclassifying the same behaviour instead of resolving it.

What practitioners underestimate: The real failure is often not lack of detection, but lack of shared accountability for the final action. When one team owns the alert and another owns the consequence, the organisation tends to accumulate unresolved cases, inconsistent customer treatment, and avoidable repeat abuse.

Practitioner takeaway: If fraud and security cannot explain the same event with the same evidence and reach the same escalation decision, they are still operating as parallel functions, not one risk function.

Related resources from NHI Mgmt Group

• What do security and risk teams get wrong about friendly fraud?
• What should compliance and security teams do when fraud risk affects investor due diligence?
• How should security teams reduce fraud risk in account recovery workflows?
• How should security teams govern fraud risk across the full user journey?