Transaction monitoring is the ongoing control that detects activity, screens for sanctions or suspicious patterns, and flags transactions that meet Travel Rule obligations. Additional risk mitigation is the broader judgement layer, where a VASP may impose tighter limits, add controls, or choose not to interact with unhosted wallets at all. One detects risk, the other sets the response.
Monitoring and mitigation solve different problems
transaction monitoring is the detective control in the workflow. It watches for patterns that look unusual, sanctions-sensitive, or inconsistent with Travel Rule obligations, then raises a signal for review. Additional risk mitigation is the decision layer that changes how the VASP interacts with the wallet, for example by limiting value, adding checks, or declining the relationship when the residual risk is too high.
The practical difference is that monitoring answers, “What is happening?” while mitigation answers, “What should we do about this wallet type or transaction pattern?” That distinction matters because a wallet can be monitored and still be allowed, or it can be flagged for controls that go beyond simple screening.
Why unhosted wallets make the distinction important
Unhosted wallets are harder to control than customer accounts held inside the VASP environment because the counterparty controls the wallet, the keys, and often the transaction path. That means a monitoring-only approach can identify suspicious behaviour, but it does not by itself reduce exposure if the underlying wallet risk is persistent, opaque, or difficult to verify.
Additional risk mitigation is where policy meets judgement. In practice, that can include tighter transaction thresholds, stronger customer due diligence, enhanced source-of-funds checks, wallet ownership verification, or refusing to proceed when the VASP cannot establish enough confidence in the transaction context.
For background on the identity and access risks that often drive these controls, see NHI Mgmt Group’s Ultimate Guide to NHIs and the section on Key Challenges and Risks.
How practitioners should separate the two in policy
Use transaction monitoring when the question is detection, alerting, and case generation. Use additional risk mitigation when the question is whether the institution should narrow, condition, or stop exposure to a particular unhosted-wallet scenario. The best policies make that escalation path explicit, so analysts do not improvise thresholds case by case.
- Define the monitoring triggers that automatically create review work.
- Define the escalation criteria that move a case from review to extra controls or rejection.
- Keep the decision criteria aligned with sanctions, AML, and Travel Rule obligations, not just transaction value.
- Review whether the mitigation decision is documented well enough to defend to audit, compliance, and regulators.
Practitioner takeaway: Monitoring is only useful if it feeds a clear response model, because unhosted-wallet risk is often managed by policy decisions, not by alerts alone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while CIS Controls v8, NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS 6 — Access Control Management | Unhosted-wallet mitigation often depends on limiting who and what can transact or approve. |
| Recommendation — Apply CIS 6 to restrict approvals, thresholds, and wallet-related access to the minimum needed. | ||
| NIST CSF 2.0 | DE.CM — Continuous Monitoring | Transaction monitoring is a continuous detection activity that watches for suspicious or sanctions-sensitive activity. |
| PR.AA — Identity Management, Authentication, and Access Control | Additional risk mitigation can require stronger verification before a wallet interaction is allowed. | |
| GV.RM — Risk Management Strategy | The mitigation layer is a governance choice about acceptable residual risk and treatment thresholds. | |
| Recommendation — Use DE.CM to monitor wallet-related transactions and route anomalies into case handling. Use PR.AA to require stronger verification and access conditions before permitting higher-risk wallet activity. Use GV.RM to define when unhosted-wallet exposure is reduced, constrained, or declined. | ||
| NIST SP 800-63 | IAL — Identity Assurance Level | Wallet-owner verification and related checks often depend on assurance strength in customer due diligence. |
| Recommendation — Map wallet-owner verification to the required assurance level before accepting higher-risk activity. | ||
| OWASP Non-Human Identity Top 10 | NHI-04 — Credential Rotation and Lifecycle | Unhosted-wallet controls often hinge on whether related keys, tokens, or credentials can be governed safely. |
| Recommendation — Apply NHI-04 to govern related credentials and reduce exposure from persistent wallet-linked secrets. | ||
Related resources from NHI Mgmt Group
- What is the difference between KYC, transaction monitoring, and session intelligence in iGaming risk controls?
- What is the difference between transaction monitoring and case management in PLD?
- What is the difference between insider-risk monitoring and inline data protection?
- What is the difference between transaction monitoring and entity screening in blockchain compliance programs?
