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

Why This Matters for Security Teams

Fraud losses that cross banks, fintechs, and online platforms create an accountability problem that is really a control problem. Each organisation may only see one slice of the journey, but attackers exploit the seams: onboarding, payment initiation, device trust, credential reuse, and delayed case handling. The question is not who feels responsible in a governance sense. It is who can prove which control failed, when it failed, and whether funds can still be recovered before they clear the chain.

That is why evidence quality, timestamps, and decision logs matter as much as detection speed. Current guidance from NIST SP 800-53 Rev 5 Security and Privacy Controls emphasises traceability and auditability for coordinated response, but fraud ecosystems often move faster than internal case workflows. NHIMG research shows NHI Mgmt Group reports 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a reminder that machine-to-machine trust is often where attack paths begin and accountability becomes blurred.

In practice, many security teams encounter the accountability gap only after funds have already been dispersed across multiple institutions, rather than through intentional cross-ecosystem testing.

How It Works in Practice

Accountability should follow control ownership, not blame narratives. A bank is accountable for customer authentication, fraud scoring, and payment release controls within its environment. A fintech is accountable for onboarding checks, API security, transaction monitoring, and partner integrations. A platform is accountable for account integrity, abuse detection, and evidence preservation on its side of the workflow. Regulators and law enforcement coordinate escalation paths, typology sharing, and preservation requests, but they do not replace operational ownership.

Practically, the answer depends on whether each party can produce a defensible trail:

• Who approved the transaction or session, and on what basis?
• What signals were present at decision time, including device, identity, and behavioural context?
• Which logs, alerts, and case notes were preserved without alteration?
• How quickly could the organisation freeze, recall, or enrich a payment investigation?

This is where control design matters. Standardised evidence formats, immutable audit logging, and shared escalation playbooks improve the odds of recovery. Identity and secrets governance also matter because stolen credentials often sit behind automated fraud chains, especially where service accounts or API keys are overprivileged. NHIMG’s Ultimate Guide to NHIs notes that 97% of NHIs carry excessive privileges, which makes rapid misuse and lateral movement more likely once an attacker enters the ecosystem. For control design, NIST SP 800-53 Rev 5 Security and Privacy Controls provides a useful anchor for logging, incident response, and access accountability, while current fraud operations increasingly need cross-entity retention agreements.

These controls tend to break down when payment rails, app platforms, and fraud teams use different retention periods and incompatible case identifiers because the chain of custody becomes incomplete.

Common Variations and Edge Cases

Tighter accountability often increases operational friction, requiring organisations to balance recovery speed against legal boundaries, partner agreements, and customer experience. That tradeoff becomes sharper when funds move through instant payments, embedded finance, or cross-border platforms, where recalls may be impossible once the transfer settles.

Best practice is evolving, but there is no universal standard for this yet. In some cases, the initiating institution is the primary control owner because it approved the payment. In others, the platform that enabled account takeover or mule recruitment holds the most actionable telemetry. Shared liability models can help, but they do not solve evidence gaps unless log retention, API access, and incident handoffs are contractually defined. Where third-party processors or wallets are involved, the accountability question should be mapped to specific control points, not broad brand names. That includes where secrets are stored, who can revoke them, and which party can disable a compromised integration without waiting for a manual approval chain.

For teams building maturity, the practical standard is to make every participant answer the same three questions: what did you know, when did you know it, and what did you do next. Without that discipline, dispute resolution becomes slower than fraud movement, and accountability turns into after-the-fact attribution instead of effective prevention.

Related resources from NHI Mgmt Group

• Why do identity and fraud teams still struggle with trust when customer interactions move across digital and in-person channels?
• Why do access certifications become a control gap when identities move across jobs, systems, and cloud platforms?
• Who remains accountable when wallet-based identity is used across banks and fintechs?
• Who is accountable when laundering services move across platforms and jurisdictions?