Risk rises when institutions move from experimentation to production without clear controls for wallet screening, counterparty risk, and regulatory review. The highest exposure usually appears at approval and settlement points, where a bad address can enter the workflow. Teams should prioritise controls that map on-chain activity to policy before value moves, not after incidents or audits.
Why This Matters for Security Teams
On-chain products create the sharpest compliance risk when they move from pilot to production and start touching real money, real counterparties, and real regulatory obligations. Stablecoins and tokenized deposits are not just payment instruments; they are programmable transfer paths that can bypass the slower, more familiar controls built around core banking workflows. That is where wallet screening, sanctions review, and beneficiary validation must happen before settlement, not after.
The control problem is usually not the token itself but the workflow around it. If an institution cannot map an address to a counterparty, apply policy at approval time, and preserve an audit trail for each transfer decision, then the product becomes a compliance blind spot. NHI Management Group has documented how weak governance and compromised identities drive downstream incidents in the Oasis Security & ESG research, which is a useful reminder that machine-to-machine trust fails fast when identity is assumed rather than verified. Standards like the NIST Cybersecurity Framework 2.0 and FATF guidance both push organisations toward traceability, screening, and ongoing risk-based oversight.
In practice, many security teams encounter the real compliance exposure only after a token flow has already settled or a regulator asks how a wallet was approved.
How It Works in Practice
The highest-risk point is not broad blockchain activity in general, but the moment an institution converts policy into an on-chain action. A compliant design should treat each transfer as a controlled decision, with screening and approval attached to the wallet, counterparty, and transaction context before value moves. That means on-chain products need governance that looks more like payment operations than a passive custody model.
In practical terms, teams should combine wallet intelligence, counterparty due diligence, and policy-based routing. If a wallet is newly created, linked to an unknown VASP, or associated with a high-risk jurisdiction, the workflow should stop or require escalation. If a stablecoin transfer is tied to treasury, settlement, or client payout flows, the institution should log who approved it, what screening ran, and what evidence was retained. The Ultimate Guide to NHIs and audit perspectives is a helpful reference for why machine-driven transaction paths need explicit ownership and evidence. For broader operational controls, NIST SP 800-53 Rev 5 remains relevant for logging, access control, and auditability.
- Screen the wallet and counterparty before settlement, not after the token is issued.
- Require a documented business purpose for each on-chain transfer path.
- Separate testnet experimentation from production rails and treasury controls.
- Retain immutable logs that show policy checks, exceptions, and approvers.
Where this guidance breaks down is in high-volume, automated settlement environments that reuse shared wallets and cannot preserve transaction-level attribution cleanly.
Common Variations and Edge Cases
Tighter screening often increases latency and operational overhead, so institutions must balance compliance assurance against settlement speed and customer experience. That tradeoff becomes more pronounced when stablecoins are used for cross-border payments, market making, or tokenized deposit sweeps, where automated execution is the whole point of the product.
Best practice is evolving for omnibus wallets, layered custodial arrangements, and smart-contract-driven settlement, because there is no universal standard for how much off-chain context must be attached to an on-chain transfer. Some firms apply controls at the wallet level, while others insist on transaction-level review for higher-risk flows. The safer approach is to treat production wallets as regulated assets, not infrastructure utilities. The Top 10 NHI Issues and Guide to the Secret Sprawl Challenge show a recurring theme: operational shortcuts create hidden exposure long before an incident is visible.
For institutions designing this control set, FATF-style AML obligations and local banking supervision usually matter more than the protocol brand itself. The edge case to watch is a compliant-looking product that still allows uncontrolled wallet re-use, because that is where policy drift turns into audit failure.
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, OWASP Agentic AI Top 10 and CSA MAESTRO address the attack and risk surface, while NIST AI RMF and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-01 | Wallets and service accounts need explicit identity and ownership. |
| OWASP Agentic AI Top 10 | A-03 | Automated approval flows can act like agents and must be constrained. |
| CSA MAESTRO | M1 | Agentic workflow governance maps to runtime approval and audit needs. |
| NIST AI RMF | GOVERN | Production on-chain products need accountable AI-style governance and oversight. |
| NIST CSF 2.0 | PR.AC-4 | Least privilege and access approval are central to wallet and settlement control. |
Assign ownership, document risk decisions, and maintain continuous oversight for automated flows.
