Purpose

Ensure sanctions screening occurs at required stages and no unresolved or confirmed match proceeds improperly.

Objective

Screening is current, complete, timely, documented and linked to legally required restrictive measures and reporting.

Normative

Bitkaya shall stop onboarding, activation or transaction release when relevant screening is incomplete or unresolved. No client, UBO, wallet, or relevant counterparty may proceed where sanctions screening is incomplete, unresolved, or positively matched. If there is a possible match and it has not been cleared by Compliance, the process must stop.

Control Activity

The approved screening method checks relevant parties and wallets. Screening must happen at: onboarding (before a client or relevant party is approved); before activation / first transaction; ongoing screening of existing clients; trigger events (change in ownership or control, change in client profile, new wallet or transfer setup, material onboarding refresh, relevant adverse information, sanctions list update, internal escalation); and transaction/wallet screening (alerts reviewed before transfer is treated as cleared). At minimum, screen: client name; beneficial owner(s); directors / authorized signatories; VASP counterparties; 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. The screening tool must cover at least UN, OFAC, EU, CFATF, and applicable Curaçao / Kingdom / local restricted lists, and should refresh sanctions data automatically. Operations stops possible matches. Compliance determines disposition (false, possible, or confirmed) and directs rejection, blocking, freezing and reporting where applicable. For a confirmed true match: reject onboarding or freeze/block the relationship or transaction, and follow Bitkaya’s escalation and reporting process to FIU Curaçao and CBCS where applicable. If the tool is unavailable or list updates fail, do not treat the case as cleared; escalate to Compliance or IT immediately; do not onboard or release until resolved or an approved workaround is applied.

Evidence

  • Expected evidence: screening result and list coverage (UN, OFAC, EU, CFATF, applicable Curaçao / Kingdom / local lists).
  • Expected evidence: alert and Compliance disposition (false positive basis for closure documented; possible match escalation; confirmed match rejection/freezing/reporting).
  • Expected evidence: false-positive rationale.
  • Expected evidence: reject, block or freeze action.
  • Expected evidence: FIU or CBCS report where required.
  • Expected evidence: tool refresh and failure record (including workaround approval where applied).
  • Expected evidence: minimum records including screening result, alert details, Compliance review notes, final outcome, freeze/reject decision, and related reporting record.
  • Evidence location: compliance evidence repository and applicable operating system.
  • Retention: at least five years or longer where required.
  • Testing method: Sample onboarding, periodic, trigger and transaction screening, including possible and confirmed matches. Verify screening happened at correct stages, alerts resolved on time, records complete, and list coverage and tool settings appropriate.
  • Testing frequency: annual and after material list or tool changes.

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

Assurance Assertions

  • Required screening stages were completed.
  • Unresolved alerts did not proceed.
  • Confirmed matches produced required restrictions and reporting.

Relationships

History

  • 2026-07-26: Created from the approved KYC & CDD Manual version 1.1.