BCMS

Perform Sanctions Screening and Resolve Alerts

4 min read

Purpose

Screen relevant parties, wallets and transactions at required stages and prevent progression while an alert is unresolved.

Preconditions

  • Current relevant sanctions data and an approved screening method are available.
  • Client, ownership, counterparty, wallet or transaction identifiers are complete.

Steps

  1. Screen at the following required points: before onboarding (before a client or relevant party is approved); before activation / first transaction (where applicable, before the relationship becomes operational); during periodic review; after relevant list or profile changes; and before relevant wallet or transaction clearance.
  2. Screen, where relevant: client name; beneficial owner(s); directors / authorized signatories, where relevant; VASP counterparties or similar relevant parties; wallet addresses and blockchain exposure, where part of the toolset; and any other party linked to a transaction or relationship where sanctions exposure is possible. Screening is not limited only to clients and beneficial owners — where relevant, the screened relationship may also include intermediary entities, advisers, counterparties, and associated wallet addresses or blockchain identifiers.
  3. Use a sanctions screening tool that covers at least: United Nations; OFAC; European Union; CFATF where relevant; and any applicable Curaçao / Kingdom / local restricted lists or internal restrictions. If list coverage changes, Compliance must review the impact. Screening shall be conducted using reliable tools, current sanctions data, and documented procedures. Where supported by the toolset, sanctions lists must be refreshed automatically.
  4. If there is no alert, record the result and continue.
  5. For a possible or partial match: stop the process; collect the relevant case details; escalate to Compliance; and do not onboard, activate, or release the transaction until cleared. Sanctions alerts must be reviewed promptly.
  6. Compliance documents whether the alert is false, possible, or confirmed. Where an alert is determined to be a false positive, the basis for closure must be documented. Where an alert remains unresolved, the relationship or transaction shall not proceed until the alert has been appropriately resolved or escalated.
  7. For a confirmed true match: reject onboarding, or freeze / block the relevant relationship or transaction, where applicable; and follow Bitkaya’s escalation and reporting process. Bitkaya shall immediately take the legally required restrictive measures, including blocking or freezing. The matter must be escalated internally to Compliance without delay and handled in accordance with applicable legal and supervisory reporting and notification requirements, including to the FIU Curaçao and CBCS where applicable.
  8. Re-screen on trigger events: change in ownership or control; change in client profile; new wallet or new transfer setup; material onboarding refresh; relevant adverse information; sanctions list update affecting the case; or internal escalation requiring re-check.
  9. Retain the screening result, alert details, Compliance review notes, final outcome, freeze/reject decision, and related reporting record. All sanctions alerts, reviews, outcomes, restrictive measures, and reports must be documented and retained in accordance with Bitkaya’s recordkeeping requirements. A simple but clear record is sufficient, provided it can be retrieved later.
  10. If the tool is unavailable, list updates fail, or screening cannot be completed: do not treat the case as cleared; escalate to Compliance or IT immediately; and do not onboard or release the transaction until the issue is resolved or an approved workaround is applied.

Exceptions and Escalation

No client, beneficial owner, wallet, counterparty or transaction may proceed with incomplete or unresolved sanctions screening. If there is a possible match and it has not been cleared by Compliance, the process must stop. Senior Management only needs to be involved where the case is material, complex, or has wider business impact.

Roles

  • Operations / Business: Ensuring screening is completed at the required stage; not progressing unresolved alerts; and escalating possible matches immediately.
  • Compliance: Reviewing alerts; deciding whether a match is false, possible, or confirmed; determining whether freezing, rejection, or reporting is required; and maintaining oversight of the sanctions screening process.

Records Created

  • screening result and alert;
  • Compliance review and disposition;
  • reject, block or freeze evidence;
  • notification or reporting evidence;
  • tool failure and workaround approval.

Relationships

Assurance

Runtime effectiveness results are maintained in Odoo and assessed through the Hermes workflow tracked in ISS-HERMES-001. This note defines design, ownership, evidence expectations and testing method; it does not contain a manually maintained operation, evidence or overall effectiveness rating.

  • Design status: implemented from approved KYC & CDD Manual version 1.1

History

  • 2026-07-26: Created from sections 4 and 15 of the approved KYC & CDD Manual.

Graph View

Backlinks