How do security, fraud, and compliance teams share accountability for onchain transactions?

What shared accountability means at the transaction layer

Shared accountability only works when the teams are aligned on the same decision point: whether a transaction should be allowed, delayed, challenged, or blocked before value moves. Security is responsible for the technical enforcement path, fraud for behavioural and social signal interpretation, and compliance for illicit flow and sanctions screening, but the control objective has to be expressed as one transaction policy rather than three disconnected reviews.

That usually means the control design is anchored in a common transaction risk model, with each team contributing different evidence to the same decision. Security looks at device, session, authentication, contract, wallet, and infrastructure conditions; fraud looks at anomaly patterns, mule behaviour, account takeover indicators, and scam dynamics; compliance looks at counterparty, destination, geography, typology, and regulatory exposure. Fraud and Cyber Convergence Guide is useful here because it frames the operating model around shared signals and joint case handling rather than siloed escalation.

The practical consequence is that no team can own the entire outcome in isolation. If security blocks too late, fraud sees the loss after the fact; if fraud escalates without technical hooks, the signals do not suppress the transaction; if compliance screens without operational integration, sanctioned or illicit flows can still pass through gaps in timing, thresholds, or exception handling.

How the teams divide evidence without fragmenting control

The cleanest division is by evidence type, not by system boundary. Security should own the controls that can enforce pre-transaction or in-line prevention, including authentication strength, approval workflows, policy enforcement, and technical throttles. Fraud should own the behavioural evidence that suggests coercion, social engineering, account takeover, synthetic identity activity, or unusual transfer intent. Compliance should own the rule set and escalation path for prohibited counterparties, sanctions exposure, suspicious typologies, and reporting obligations.

The teams still need one shared workflow for high-risk events. That workflow should define what each team can veto, what each team can only recommend, and what data must be present before a transaction can proceed. FinCEN is relevant as an authoritative source for AML obligations and reporting expectations, but the operational point is broader: compliance decisions are only effective when they are wired into the transaction path, not applied after settlement or after the customer has already moved funds.

Teams also need a common evidence standard for overrides. If a transaction is approved despite elevated fraud or compliance signals, the override should be explainable, timestamped, and attributable to a named control owner or approval authority. That prevents the classic failure mode where every team sees risk, but no one can show who accepted it and on what basis.

Where joint ownership breaks down in practice

Accountability fails when the programme is organised around handoffs instead of a shared control objective. The most common breakdown is that each team optimises its own queue: security closes technical alerts, fraud closes suspicious patterns, and compliance closes screening cases, while the transaction engine remains outside all three decision loops. Another common failure is inconsistent thresholds, where one team treats a signal as blocking and another treats the same signal as advisory.

There is also a timing problem. Onchain transactions move quickly and can be difficult or impossible to reverse, so the control has to act before broadcast or at the point of authorisation. If the teams only review after the transaction is confirmed, they are doing investigation, not prevention. A converged operating model works best when each team has the same operational clock, the same escalation path, and the same view of what constitutes an unsafe transfer.

For teams building controls around wallets, keys, or other transaction-signing material, the account ownership model matters as much as the detection logic. NHI Ownership and Accountability Guide is a useful companion because it reinforces a simple governance point: if no owner is assigned to the identity or control plane that can authorise movement, accountability will fail as soon as an exception, rotation, or incident occurs.

Risk and Threat Considerations

The main risk is that unsafe value movement becomes a shared assumption instead of a shared control. In onchain environments that creates exposure to fraud loss, sanctions breaches, and irreversible transfers, especially when approvals are split across teams that do not share the same data, timing, or veto authority.

Failure mechanism: A scam, compromise, or prohibited transfer is detected in one workflow but not translated into an immediate transaction control, so the payment or transfer is still signed and broadcast.

Impact: The organisation can suffer unrecoverable loss, regulatory exposure, and post-incident disputes over who was responsible for stopping the transaction.

Practitioner Guidance

What to prioritise: Define one control objective for transaction safety, then map each team to a distinct evidence class and decision right. If a team cannot influence the transaction before value moves, it is not part of the prevention control, only the downstream review process.

What to verify: Confirm that every high-risk transaction path has a named owner, an escalation threshold, and a blocking control that is actually wired into the signing or release step. Verify that fraud, security, and compliance each see the same transaction context before they are asked to approve, challenge, or reject it.

Practitioner takeaway: Shared accountability works only when the teams share one decision surface; if they do not converge at the transaction layer, they are sharing responsibility without sharing control.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• How do finance, security, and operations teams share accountability for preventing fraud and business email compromise?
• How do compliance, fraud and legal teams share accountability in a new licensing regime?