Objective
Ensure sanctions screening occurs at required lifecycle points and unresolved or true matches are escalated before activity proceeds.
Control Activity
Compliance confirms that applicable clients, related parties, intermediaries, counterparties, wallets and transactions are screened at each required lifecycle point using current UN and EU data and other applicable OFAC, CFATF, Curaçao, Kingdom, local and internal lists. Prohibited-jurisdiction activity and unresolved alerts must not proceed, false-positive rationale must be retained, and confirmed matches must trigger legally required restrictions plus separate FIU and CBCS assessments.
Lifecycle Screening Points
Sanctions screening is a mandatory control applied:
- Before onboarding
- Before activation of a relationship
- During periodic review
- Upon relevant trigger events
- When sanctions lists are updated or refreshed
- Before execution, settlement, release, or completion of any relevant transaction
For transaction-related activity, Bitkaya must screen the relevant transaction counterparty before the transaction is executed, settled, released, or otherwise treated as cleared.
Required Parties to Screen
At minimum, where applicable:
- The client
- Beneficial owner(s) (UBOs)
- Directors, authorized representatives and signatories
- Intermediary entities or persons involved in the relationship or transaction
- VASP counterparties and other relevant institutional counterparties
- Wallet addresses, blockchain identifiers and relevant blockchain exposure
- Bank-account holders or payment counterparties where relevant to the transaction
- Any other party linked to a relationship or transaction where sanctions exposure may arise
Required Sanctions Lists (Minimum Coverage)
- United Nations sanctions lists
- European Union sanctions lists
Additional lists where applicable to Bitkaya’s business, client base, counterparties, jurisdictions, payment flows, or risk profile:
- OFAC (US Treasury Office of Foreign Assets Control)
- CFATF (Caribbean Financial Action Task Force)
- Curaçao / Kingdom / local sanctions or restricted lists
- Internal restricted-party or restricted-jurisdiction lists
Prohibited Jurisdictions
Jurisdictions subject to comprehensive UN sanctions, EU sanctions, applicable Kingdom sanctions measures, or any other sanctions regime that legally prohibits or materially restricts the provision of services are classified as Prohibited Jurisdictions — not merely high-risk. Prohibited jurisdictions are outside Bitkaya’s risk appetite. Bitkaya shall not establish or maintain relationships, process transactions, provide wallet services, facilitate transfers, or otherwise provide services involving a prohibited jurisdiction. Prohibited jurisdictions are not eligible for risk acceptance through EDD, risk mitigation measures, or management approval where applicable sanctions laws prohibit the activity.
True-Match Handling
Where a sanctions alert is confirmed as a true match, Bitkaya must immediately:
- Apply legally required restrictive measures (blocking, freezing, rejecting, refusing, or restricting)
- Escalate internally to Compliance without delay
- Execute applicable FIU Curaçao reporting obligations
- Execute applicable CBCS notification or reporting obligations
- Document all actions taken, including timing, ownership, rationale, and outcome
Bitkaya distinguishes between: internal sanctions escalation; FIU reporting obligations; CBCS supervisory reporting or notification obligations; and operational freezing or blocking measures.
Unresolved Alert Stop Control
Where an alert remains unresolved, the relationship, transaction, wallet setup, payment, transfer, settlement or release must not proceed until the alert has been appropriately resolved or escalated. Where an alert is determined to be a false positive, the basis for closure must be documented.
Evidence
- Expected evidence: screening result.
- Expected evidence: alert disposition.
- Expected evidence: escalation record.
- Expected evidence: restrictive measure record.
- Expected evidence: sanctions-list coverage and refresh evidence.
- Expected evidence: prohibited-jurisdiction and FIU/CBCS decision evidence.
- Evidence location: compliance evidence repository and applicable operating system.
- Retention: according to Bitkaya AML/CTF/CPF record-retention requirements.
- Testing method: Sample onboarding, periodic, trigger, list-refresh and transaction cases; confirm party and wallet coverage, current lists, prompt review, false-positive support, unresolved-alert stop controls, prohibited-jurisdiction treatment, restrictive measures and separate FIU/CBCS decisions.
- Testing frequency: annual, and after material AML/CTF/CPF changes where applicable.
Relationships
- Policy: POL-AML-001 AML CTF CPF Compliance Manual
- Process: PRC-FCI-001 Financial Crime and Integrity
- Procedures: PROC-AML-003 Perform Sanctions Screening and Restrictive Measures Escalation
- Manual coverage: sections 4.3, 4.4 and 5.4.
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 AML/CTF/CPF Compliance Manual version 2.2
History
- 2026-07-26: Expanded lifecycle, list coverage, prohibited-jurisdiction, stop-control and reporting-decision testing after a full manual rescreen.
- 2026-07-26: Created from the approved AML/CTF/CPF Compliance Manual version 2.2.