Who is accountable when fraud losses move across banks, fintechs, and online platforms?

Why Accountability Becomes Fragmented Across the Fraud Chain

When fraud spans banks, fintechs, and online platforms, accountability usually follows control boundaries rather than the victim’s experience. That means the question is not who “owns” the whole event in a moral sense, but which organisation controlled onboarding, authentication, payment initiation, monitoring, case handling, and recovery at each step. The NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it frames accountability around control ownership, evidence, and traceability rather than vague responsibility.

Practitioners often get this wrong by treating cross-channel fraud as a single incident with a single owner, when in reality the accountable party shifts as the transaction moves through separate legal entities and trust boundaries. That distinction matters because weak handoffs, unclear logging, and inconsistent escalation rules are what allow losses to move faster than the organisations can coordinate.

In practice, many teams discover their accountability gaps only after disputed payments, failed recalls, or missing logs have already made recovery and attribution much harder.

How Accountability Should Work Across Banks, Fintechs, and Platforms

The cleanest way to think about this question is to map accountability to the part of the chain each participant actually controls. A bank may be accountable for account servicing, payment rail participation, sanctions screening, and suspicious activity reporting. A fintech may be accountable for onboarding checks, transaction monitoring, customer verification, and how it routes instructions into downstream rails. An online platform may be accountable for marketplace abuse controls, seller or user vetting, device intelligence, and the abuse signals it can detect before a payment ever reaches a bank.

That does not mean each party can dismiss the wider fraud outcome. Where an ecosystem participant has the ability to prevent, detect, or slow fraudulent movement, it has a governance duty to use that capability and preserve evidence that supports attribution and recovery. The practical standard is whether the organisation can show who approved what, what signals were available, what action was taken, and when the decision was escalated. Without that chain of evidence, accountability becomes a post-incident argument instead of an operational control.

Cross-entity fraud also introduces dependency risk. A strong internal control can still fail if a downstream partner cannot freeze funds, if upstream identity checks are weak, or if case management is too slow to trigger interbank action. Shared accountability therefore needs explicit operating agreements, not just contractual language. Those agreements should define who investigates, who notifies, who can block, who can recall, and what minimum evidence each party must retain to support enforcement or reimbursement decisions.

• Ownership should follow the control point, not the brand most visible to the customer.
• Evidence should be retained in a way that supports later dispute resolution, not just internal review.
• Escalation should be fast enough to interrupt fund movement before recovery options close.

This guidance breaks down when the organisations involved have no shared telemetry, no usable legal path for information exchange, or no operational ability to act on a warning in time.

Where Shared Responsibility Turns Into Gaps, and What Practitioners Miss

Shared accountability often increases coordination overhead, requiring organisations to balance speed against proof and autonomy against interoperability. The hardest edge case is the handoff between a platform that first sees the abuse and a regulated institution that can actually stop the money. Industry consensus is still uneven on how far each actor’s duty extends before a transaction becomes a matter for another entity, so practitioners should treat “we passed it on” as insufficient unless the receiving party can act on it.

Another common edge case is when one participant has visibility but not authority. A fintech may detect risk early, yet lack the operational power to freeze the funds once they move into a bank account. Conversely, a bank may have the ability to hold or recall funds, but only after delays that erase the value of the alert. That is why the question of accountability should be paired with decision rights, timelines, and retention requirements, not only with legal responsibility.

The most overlooked issue is that fraud accountability is often tested by evidence quality as much as by policy. If a party cannot reconstruct the sequence of authentication, approval, transfer, and intervention, it cannot credibly argue that it met its obligations. In a multi-party fraud chain, traceability is not administrative detail; it is part of the control itself.

Practitioner Guidance

What to prioritise: Define the control point, the decision owner, and the escalation trigger for every stage where fraud can be detected or interrupted. If no party can name those three elements for a specific handoff, accountability is already too diffuse to support recovery.

What to verify: Confirm that logs, timestamps, case notes, and notification paths are sufficient to reconstruct who knew what, when they knew it, and what they did next. If the evidence cannot support a dispute or regulatory review, the control is weaker than it appears.

What practitioners underestimate: The recovery window is usually shorter than the governance discussion. By the time a cross-entity escalation is debated, the funds may already have moved beyond practical recall, which makes speed a control objective rather than a convenience.

Practitioner takeaway: In multi-organisation fraud, accountability is only real when it is tied to a specific control, a specific decision, and a specific evidence trail that can survive later challenge.

Related resources from NHI Mgmt Group

• Who remains accountable when wallet-based identity is used across banks and fintechs?
• Who is accountable when laundering services move across platforms and jurisdictions?
• How should security teams make NHI best practices usable across the business?
• Who is accountable when a compromised SaaS integration is used to move across multiple clouds?