Accountability usually sits with the compliance, AML, and investigations teams that own transaction monitoring, screening, and case escalation. Security and data teams may support the controls, but the governance decision is whether the organisation can explain fund flows, preserve evidence, and act on alerts consistently across the network and its adjacent systems.
Who Owns Screening and Flow Tracing on a New Blockchain Network?
When a stablecoin touches a new blockchain network, accountability is not just about who can see the transactions. It is about who owns the operating model for screening addresses, reviewing alerts, tracing related flows, and deciding when a case becomes a compliance event. The practical answer is that those responsibilities usually sit with compliance, AML, and investigations functions, because they own the judgment call between a suspicious pattern and an explainable transfer path.
That ownership matters because blockchain monitoring rarely stays inside one tool or one team. Screening, attribution, evidence retention, and escalation often depend on data quality from wallet infrastructure, chain analytics, customer records, and sanctioned-entity checks. NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because the control mindset extends beyond detection into logging, accountability, and review discipline, which are the conditions that make later investigation credible. In practice, many organisations discover the ownership gap only after an alert must be explained across systems that were never joined up for case handling.
How Screening and Tracing Actually Work Across the Network
On a new blockchain network, screening and tracing are not single actions but a chain of decisions. First, the organisation needs a reliable view of which addresses, wallets, contracts, bridges, and counterparties are in scope. Then it needs a screening model that can compare those addresses against sanctioned entities, known illicit infrastructure, internal watchlists, and risk indicators tied to the transfer context. After that, investigators need a way to follow the fund path across hops, token contracts, custodial transitions, and adjacent services without losing evidence.
The key operational question is who owns each handoff. Compliance may own the policy for what triggers a review, AML may own transaction monitoring and dispositioning, investigations may own tracing and narrative building, and engineering or data teams may own the feeds, normalisation, and lineage needed to make the results trustworthy. If those roles are not explicit, the organisation can end up with fragmented alerts, duplicated work, or no one willing to sign off on the final interpretation.
Zero Trust thinking is still relevant because it discourages assuming that a network, wallet, or bridge is safe simply because it is newly onboarded. NIST SP 800-207 Zero Trust Architecture is useful here for the broader principle of verifying each transaction path and trust dependency rather than inheriting confidence from the environment. The practical lesson is that tracing must be repeatable: the same input should produce the same explanation, or the organisation will struggle to defend its decisions to auditors, counterparties, or regulators.
- Define which team owns screening logic, which team owns case review, and which team owns escalation.
- Keep address, entity, and transaction lineage separate so investigators can reconstruct flow paths later.
- Validate whether the network introduces new blind spots, especially around bridges, wrapped assets, and custodial intermediaries.
This guidance breaks down when the organisation treats blockchain monitoring as a one-time onboarding task rather than an ongoing control with named operational ownership.
Where the Ownership Model Gets Messy in Real Deployments
Tighter screening usually increases operational overhead, so organisations must balance speed against explainability. That trade-off becomes visible when a network has mixed custody models, privacy-enhancing features, or incomplete address intelligence, because the same transfer may look different depending on the data source and the point in the flow where it is inspected.
One common edge case is a network that is technically new but economically connected to existing venues through bridges or shared liquidity. In that situation, the question is not whether a team can name the destination address, but whether it can attribute the relationship with enough confidence to support an alert disposition. Another edge case is when screening output is high volume but low quality, which can happen if the team lacks clear watchlist governance or if false positives are never fed back into the rule set. The consensus view is that ownership should sit with the function that can make a defensible compliance decision, not simply the function that operates the analytics tool. What practitioners underestimate is that unresolved data lineage problems become governance problems very quickly once a suspicious flow must be explained externally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK address the attack and risk surface, while NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR — Roles, Responsibilities, and Authorities | Ownership of screening and tracing requires clear accountable roles. |
| Recommendation — Assign named owners for screening, tracing, and escalation decisions. | ||
| CIS Controls v8 | 8 — Audit Log Management | Tracing suspicious flows depends on retained, reviewable transaction evidence. |
| Recommendation — Retain and review logs that support end-to-end flow reconstruction. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Address attribution and counterparty trust depend on identity confidence. |
| Recommendation — Set identity-assurance thresholds before trusting address attribution. | ||
| MITRE ATT&CK | T1071 — Application Layer Protocol | Cross-network fund movement often hides within normal-looking protocol traffic. |
| Recommendation — Map suspicious transfer paths to observed protocol and hopping patterns. | ||
Practitioner Guidance
What to verify: Confirm that one team is explicitly accountable for the screening decision, one for the tracing record, and one for escalation ownership. If those roles are blended, the organisation usually inherits gaps in evidence, sign-off, or follow-through.
What practitioners underestimate: The hardest part is not detecting a suspicious flow but preserving a defensible explanation of how the conclusion was reached. If the network data, wallet attribution, and case notes cannot be reconstructed later, the control is weaker than it appears.
Practitioner takeaway: The right accountability model is the one that can survive review, not the one that merely produces alerts; if no team can explain the flow chain end to end, ownership is not yet real.
Related resources from NHI Mgmt Group
- How should security teams make NHI best practices usable across the business?
- How should exchanges detect illicit crypto flows when criminals spread activity across many addresses?
- Who is accountable when a defence network compromise spreads across connected systems?
- What breaks when token support is not updated automatically as new assets are minted on a blockchain network?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
