Who is accountable when fraud begins on a third-party platform?

Why This Matters for Security Teams

When fraud starts on a third-party platform, accountability is often split across product teams, fraud operations, security, legal, and the external platform itself. That fragmentation matters because the failure usually is not a single missed alert; it is a broken chain of control points where warnings, access, and customer intervention should have stopped the loss. The same pattern shows up in supply-chain incidents like the Reviewdog GitHub Action supply chain attack, where trust in an upstream service or integration can expose downstream systems faster than human review can react.

For security teams, the hard part is proving which party owned each stop on the path to payment, especially when the fraud path crosses identity, device, messaging, and transaction layers. Current guidance from the OWASP Non-Human Identity Top 10 reinforces that third-party access and service-to-service trust need explicit governance, not assumptions. NHI Management Group research also shows that 92% of organisations expose NHIs to third parties, raising concerns about supply chain security. In practice, many security teams encounter accountability gaps only after the customer has already moved money, rather than through intentional control testing.

How It Works in Practice

Accountability for third-party fraud should be mapped to control ownership, not blamed as a single event. The platform typically owns identity proofing, account integrity, abuse detection, device and session signals, and the speed of reporting and takedown. The financial institution usually owns transaction monitoring, payment holds, customer warning workflows, beneficiary checks, and the decision to delay or reject outgoing transfers. Response teams own escalation paths, evidence preservation, and whether controls are tuned to catch platform-originated fraud before it reaches irreversible channels.

That division works best when the organisation documents who can intervene at each stage and what evidence is required to act. For example, a scam that begins with a compromised account on a third-party marketplace may still be stoppable if the bank has real-time payment screening, if the platform can freeze the account quickly, and if customer service can validate and escalate an unusual transfer request. The 52 NHI Breaches Analysis is useful here because it shows how upstream compromise often becomes a downstream loss when identity trust is too broad. In the same spirit, the LiteLLM PyPI package breach illustrates how third-party compromise can create direct exposure when credentials and trust are not bounded tightly enough.

• Define which party owns detection, warning, freeze, refund, and escalation decisions.
• Set time-bounded response obligations in contracts and operational runbooks.
• Require evidence sharing so each party can prove what it saw and when.
• Measure loss prevention by control point, not just by total fraud volume.

These controls tend to break down when the fraud chain spans multiple vendors and payment rails because no single party has full visibility or authority to stop the transaction.

Common Variations and Edge Cases

Tighter fraud controls often increase friction, requiring organisations to balance faster customer experience against stronger intervention and review. That tradeoff becomes sharper when the fraud originates on a platform that is not the bank’s direct customer interface, because the bank may see only the payment event while the platform sees the initial abuse signal.

There is no universal standard for this yet, but current guidance suggests that accountability should follow the control point with the best opportunity to interrupt harm. In some cases, the platform is accountable for weak abuse detection or slow account action; in others, the financial institution is accountable for approving a suspicious transfer that should have been held. Shared accountability is not the same as shared fault. It means each party must own the part of the kill chain it can realistically stop.

That distinction matters most in cross-border cases, peer-to-peer payments, and agent-assisted fraud, where automated workflows move faster than manual escalation. The question is not whether fraud started elsewhere; it is whether the organisation had a timely control that could still have prevented customer loss. In practice, many disputes are settled only after the money is gone, which is why pre-agreed escalation and evidence standards matter as much as the detection logic itself.

Related resources from NHI Mgmt Group

• Who should be accountable for third-party access removal?
• Who is accountable for SaaS security when third-party apps are involved?
• Who is accountable when third-party or guest device access is over-extended?
• Who should be accountable for third-party NHI access?