Sanctions risk does not sit only at onboarding. A legitimate user can still send value to a sanctioned wallet, sanctioned jurisdiction, or sanctioned service provider later in the relationship. Screening both the customer and the counterparty reduces blind spots, especially when corporate entities, exchanges, and other services can themselves become designated after initial review.
Why sanctions screening has to follow the payment path, not just the customer record
Sanctions controls are only reliable when they reflect how value actually moves. A customer can be clean at onboarding and still create prohibited exposure later by paying a sanctioned wallet, service provider, exchange, or jurisdiction. Screening counterparties keeps the control aligned to the transaction itself, which is where a sanctions breach actually occurs.
Customer-only screening also misses changes that happen after initial approval. Counterparties can be newly designated, restructured, or obscured through intermediaries, so the control has to evaluate the recipient or receiving service in context, not just the account holder.
When sanctions exposure is tied to transaction flow, the practical question is whether your monitoring sees both the originator and the destination relationship. That is especially important for cross-border payments, digital asset transfers, and corporate-to-corporate activity where the named user and the entity receiving value may not be the same risk object.
- Screen the customer at onboarding and at review points.
- Screen the counterparty at transaction time and against updated lists.
- Re-screen when routing, intermediary, or destination details change.
For broader control design, this is where transaction monitoring and sanctions governance intersect, because the control has to catch both static customer risk and dynamic counterparty risk in the same process.
Why counterparty screening closes the blind spots that onboarding cannot
The main blind spot is time. Onboarding tells you who the customer was when they entered the relationship, but sanctions exposure can emerge later through payments to a designated wallet, exchange, merchant, shipper, or other service provider. If you only screen the user, you are assuming the counterparty will never become relevant to sanctions risk, which is often false.
Another blind spot is structure. Corporate groups, payment processors, and exchanges can sit between the user and the ultimate destination, and those relationships can change quickly. Counterparty screening helps detect when the transaction itself introduces a prohibited nexus, even if the customer profile still looks acceptable.
That distinction matters because sanctions regimes are not only about known bad customers. They also prohibit dealings with restricted persons, entities, jurisdictions, and in some cases services that become designated after earlier clearance. A control that does not inspect the destination cannot reliably prevent that exposure.
For organisations that need a practical benchmark, the sanctions workflow should answer two separate questions: “Can we accept this customer?” and “Can we execute this transfer to this counterparty now?” Both need a current answer for the control to hold up operationally.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and CIS Controls v8 set the technical controls, while DORA and NIS2 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RM — Risk Management Strategy | Sanctions screening is a risk-control decision that must track changing exposure over time. |
| Recommendation — Align screening to evolving sanctions risk and update controls when counterparties or destinations change. | ||
| CIS Controls v8 | 5 — Account Management | Customer and counterparty screening depends on knowing which accounts can initiate or receive transfers. |
| 8 — Audit Log Management | Screening decisions need transaction evidence and traceability for review and investigation. | |
| Recommendation — Maintain accurate account and counterpart records so screening can evaluate both parties to a transfer. Log screening results for both users and counterparties so you can reconstruct why a transfer was allowed or blocked. | ||
| DORA | ICT-3 — ICT Third-Party Risk Management | Counterparty screening must account for service providers and intermediaries that can become restricted over time. |
| Recommendation — Assess third-party and intermediary exposure whenever a transaction depends on an external service or route. | ||
| NIS2 | A.5 — Supply Chain Security | Sanctions exposure can arise through counterparties and service chains that change after onboarding. |
| Recommendation — Extend screening and oversight to relevant counterparties in the transaction chain, not only the direct customer. | ||
Practitioner Guidance
What to verify: Make sure screening logic is attached to the transaction object, not only the customer master record. If the system cannot inspect beneficiary, wallet, merchant, routing, or intermediary data at decision time, you have a control gap rather than a tuning issue.
Decision rule: If the customer is clear but the counterparty is uncertain, treat the transaction as high risk until the counterparty is resolved. In practice, that means escalation should be driven by destination risk, not by the customer’s clean onboarding result.
What practitioners underestimate: Counterparty risk is often dynamic, so periodic list updates are not enough on their own. The control has to support re-screening at execution time and after material changes in destination details, otherwise sanctions exposure can appear between review cycles.
Practitioner takeaway: The strongest sanctions programmes screen the relationship and the transfer, because prohibited exposure is created by where value goes, not just by who first opened the account.
Related resources from NHI Mgmt Group
- What breaks when sanctions screening does not cover historical transactions?
- How should crypto service providers adapt sanctions screening when the EU expands transaction bans to entire third countries?
- Why do healthcare identity controls need to cover non-human identities too?
- Why do service accounts and AI agents need different controls from human users?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
