KYC and CDD Manual

Policy Statement

Bitkaya shall identify and verify clients, beneficial owners, controllers and representatives; understand the purpose and intended nature of each relationship; classify risk; apply proportionate CDD or EDD; screen relevant parties and wallets; monitor activity; escalate unusual or suspicious matters; and retain an auditable client file.

No relationship may be activated when required identity, ownership, screening, risk classification, approval or enhanced-review steps remain incomplete. Prohibited relationships must not proceed. Restricted relationships require documented Compliance and, where applicable, Senior Management approval.

Scope

This policy applies to prospective and existing individual, corporate and institutional clients; beneficial owners and authorized persons; relevant VASP counterparties; introducers and agents; wallets and transactions where screening is required; and re-entry requests following a financial-crime exit.

Roles

The Board approves the framework and receives quarterly compliance updates.
Compliance and the MLRO own risk methodology, escalation, FIU reporting, proportionality decisions and control oversight.
Operations collects and verifies information, prepares risk classifications and maintains client files.
Management approves low- and medium-risk relationships; high-risk relationships also require Compliance approval.
Independent review assesses design and operating effectiveness.

Change Log

Version	Date	Summary of Changes	Approvers	Impacted Policies/Procedures	Notes
1.0	October 2025	Initial Manual	Board	All
1.1	April 2026	Cross-manual harmonization following AML/CTF/CPF Manual v2.1	Board
1.2	July 2026	Added SRC-AML-001 to sources; added PB 2026 nr. 35 CDD thresholds and high-risk jurisdiction reference.	MD	1	CHG-RES-001, CHG-RES-005

1 Purpose and Scope

This manual defines the framework for Know Your Customer (KYC) and Client Due Diligence (CDD) procedures at BitKaya. It ensures compliance with Curaçao’s regulatory requirements, adherence to FATF recommendations, and alignment with international best practices for Virtual Asset Service Providers (VASPs).

The core objective is to prevent money laundering (ML), terrorist financing (TF), and proliferation financing (PF) by verifying client identities, assessing risk exposure, and monitoring activities across the entire client relationship.

BitKaya’s Customer Due Diligence (CDD) program forms a central pillar of its AML/CFT compliance system. The program is designed to identify, assess, and mitigate financial crime risks at every stage of the client lifecycle. It is structured around four interconnected components: KYC / KYT / KYV layers, Sanctions Screening, Risk Profiling, and Transaction Monitoring.

Together, these components establish a comprehensive, risk-based framework that enables BitKaya to achieve both regulatory compliance and effective financial crime risk management.

This framework applies to all onboarding, transaction monitoring, and ongoing relationship management involving retail clients, corporate entities, institutional investors, and third-party intermediaries.

Current CDD monetary thresholds, high-risk jurisdiction lists, and required identification documents are designated by PB 2026 nr. 35 (Regeling aanwijzing bedragen, landen, staten en documenten dienstverleners), which is the current subordinate regulation under the NOIS/LID framework (SRC-LID-001 Landsverordening identificatie bij dienstverlening). CDD procedures must reference PB 2026 nr. 35 for the current threshold values and high-risk country lists.

2 KYC/KYT/KYV — Foundational Due Diligence Layers

Bitkaya integrates three complementary due diligence domains to establish a complete understanding of the client and their activity:

2.1 KYC (Know Your Customer)

Bitkaya verifies each client’s identity at onboarding using a reliable identification and verification process appropriate to the client’s risk profile and the nature of the relationship.

For natural persons, Bitkaya collects and verifies sufficient information to establish the client’s identity before the relationship is activated. Individuals must provide a valid passport, national identity card, cedula, or driving licence, and complete any required liveness, biometric, or authenticity checks applied through Bitkaya’s onboarding process.

For legal entities, Bitkaya collects and reviews documentation sufficient to establish the entity’s legal existence, ownership and control structure, authorized representatives, and beneficial ownership. The extent of verification and supporting evidence required is determined on a documented risk basis and may include registry extracts, incorporation documents, constitutional documents, authorized signatory evidence, ownership documentation, and supporting identification records for relevant natural persons.

These steps ensure that only clients whose identity, legal existence, and control structure can be adequately established and understood are permitted to access Bitkaya’s services.

2.2 KYT (Know Your Transaction)

Bitkaya monitors client activity across both fiat and virtual asset transactions using blockchain analytics, internal review, and rule-based monitoring scenarios designed to identify unusual or suspicious activity.

Monitoring is calibrated to the client’s risk profile and includes review of transaction size, frequency, velocity, pattern, source, destination, exposure to higher-risk wallets or services, suspicious wallet connections, unusual routing behaviour, and consistency with known client information, expected activity, and the stated purpose and nature of the relationship.

Alerts generated through automated tools or manual review are subject to further assessment, escalation, and documentation in accordance with Bitkaya’s AML/CTF/CPF procedures.

2.3 KYV (Know Your VASP)

Counterparty due diligence is applied to relevant VASP relationships to prevent indirect exposure to illicit actors through VASP-to-VASP transfers, routing of assets, or other forms of counterparty reliance.

The extent of KYV measures is determined on a documented risk basis, taking into account the nature of the relationship, the jurisdiction of the VASP, its regulatory or supervisory status, the services involved, transaction flows, and any other relevant risk indicators.

The Know Your VASP compliance file contains, as appropriate to risk:

licence and/or information regarding the regulatory supervisor;
company registry extract;
certificate of incorporation or equivalent registration document;
ownership and control information where relevant;
sanctions screening results;
independent data sources, including electronic business information sources; and
any additional supporting information required to understand the counterparty’s role, risk, and control environment.

Bitkaya does not apply simplified treatment automatically solely because a VASP is established in a particular jurisdiction or claims to be regulated. Any simplified approach must be justified by documented risk assessment.

3 Client Onboarding Procedures

BitKaya is committed to maintaining the highest standards of compliance and integrity when onboarding clients. Whether an individual investor, a corporate entity, or an institutional client, each relationship begins with a robust KYC and CDD process designed to safeguard against financial crime risks.

The onboarding framework combines traditional verification methods with advanced digital onboarding technologies, ensuring speed, security, and compliance with Curaçao’s regulatory framework and FATF standards.

3.1 Individual Clients

Identification Documents: Clients must provide a valid passport, national ID, cedula, or driver’s licence, together with proof of residential address where required under Bitkaya’s onboarding procedures.
Verification: Information is cross-checked using appropriate screening and verification tools, including sanctions screening, PEP screening, adverse information checks where required, and wallet or transaction analysis where relevant to the relationship.
Source of Funds / Source of Wealth: The level of financial background information collected depends on the client’s risk classification.
- For low-risk individual clients, Bitkaya collects the minimum information necessary to understand the purpose and intended nature of the relationship and the expected level of activity.
- For medium-risk individual clients, source of funds information must be collected, at minimum on a self-declaration basis, supported by additional information where required by the facts and circumstances.
- For high-risk individual clients, source of wealth must be assessed before approval. Supporting documentation must be obtained where necessary to substantiate the client’s source of wealth and source of funds, and enhanced review must be performed where the circumstances require deeper understanding of the client’s financial profile or transaction activity.
No individual client relationship may be activated until the applicable due diligence requirements, approvals, and sanctions checks have been completed.

3.2 Corporate Clients

Corporate Documents: Bitkaya collects documentation sufficient to establish the legal existence, structure, ownership, and authority of the corporate client. Depending on risk, this may include a certificate of incorporation, chamber or company registry extract, articles of association or equivalent constitutional documents, register of directors or shareholders, authorized signatory evidence, and other supporting corporate records.
Beneficial Ownership: Bitkaya identifies the natural persons who ultimately own or control the legal entity and assesses whether the ownership and control structure can be adequately understood. Supporting documentation and verification measures are applied on a documented risk basis.
- For low-risk corporate clients, the minimum file should ordinarily include at least:
  - a recent registry extract or equivalent official corporate record;
  - a signed UBO declaration;
  - identification of the authorized signatory or representative;
  - sanctions and PEP screening results for the entity, authorized signatory, and declared UBOs; and
  - documentation of the purpose and intended nature of the relationship.
- For medium-risk and high-risk corporate clients, Bitkaya applies additional measures proportionate to risk, which may include supporting ownership evidence, additional verification of controllers and signatories, financial background information, source of funds or source of wealth review where relevant, and enhanced adverse information screening.
Business Activity: Bitkaya must understand the nature of the client’s business, expected use of Bitkaya’s services, and whether the activity is consistent with the client’s profile, jurisdiction, and ownership structure.

3.3 Digital Onboarding (BitKaya.io)

3.3.1 Identity Verification

eKYC Integration: BitKaya.io uses biometric verification, liveness detection, and AI-driven fraud detection to validate clients.
Document Uploads: Users securely upload passports, IDs, or driver’s licenses through BitKaya.io’s onboarding portal.
Automated Verification: Cross-checks are conducted with government databases and document authenticity checks.

3.3.2 Proof of Address

Clients upload digital proof of address such as utility bills or e-statements.
Verification is supported by geolocation metadata and trusted third-party databases.

3.3.3 Sanctions and PEP Screening

Real-time integration with AML/KYC tools ensures ongoing screening against OFAC, UN, EU, and CFATF lists.
Alerts are updated continuously, reflecting regulatory changes.

3.3.4 Source of Funds / Wealth

Bitkaya collects source of funds and, where required, source of wealth information in a manner proportionate to the client’s risk profile.
For medium-risk clients, source of funds must at minimum be collected on a self-declaration basis, with additional support requested where the circumstances warrant it.
For high-risk clients, source of wealth must be assessed before approval. Supporting documentation must be obtained where necessary to substantiate the legitimacy and plausibility of the client’s wealth and relevant transaction funding.
Where virtual asset activity forms part of the funding profile, blockchain tracing, wallet review, and other transaction analysis tools may be used to support the assessment. The extent of tracing and review must be documented in the client file where enhanced review is required.

3.3.5 Risk Rating and Approval

Each client is assigned a documented risk rating based on Bitkaya’s risk-scoring methodology.

Low-risk and medium-risk clients require management approval before activation of the relationship.
High-risk clients require Compliance approval in addition before onboarding may be completed.
Where sanctions alerts remain unresolved, onboarding may not proceed until the alert has been appropriately resolved or escalated in accordance with Bitkaya’s sanctions procedures.
Where high-risk classification triggers enhanced due diligence requirements, including source of wealth assessment, those requirements must be completed before approval is granted.

3.3.6 Security & Data Protection

BitKaya.io complies with GDPR-style data protection standards.
Multi-layer encryption safeguards client data both during transmission and storage.

3.3.7 Ongoing Digital Monitoring

Bitkaya uses digital tools, blockchain analytics, screening systems, and internal review processes to monitor client activity on an ongoing basis.
Suspicious or unusual activity identified through monitoring is reviewed by the Compliance function and handled through Bitkaya’s internal case-management workflow. Internal classifications may be used to support review, escalation, and documentation.
Where external reporting to the FIU Curaçao is required, Bitkaya files a Unusual Transaction Report (UTR) in accordance with applicable law and internal procedures.

4 Sanctions Screening — Ongoing Exposure Management

Bitkaya performs sanctions screening on an ongoing basis as part of its AML/CTF/CPF and sanctions control framework.
At a minimum, sanctions screening shall occur:
- before onboarding or activation of a relationship;
- during periodic review;
- when relevant sanctions lists are updated or refreshed; and
- before or during relevant transactions where the control framework requires transaction-level or wallet-level screening.
For sanctions purposes, screening is not limited only to clients and beneficial owners. Where relevant, the screened relationship may also include directors, authorized signatories, intermediary entities, advisers, counterparties, and associated wallet addresses or blockchain identifiers where screening forms part of the control framework.
Screening shall be conducted using reliable tools, current sanctions data, and documented procedures. Where supported by the toolset, sanctions lists must be refreshed automatically.
Sanctions alerts must be reviewed promptly and escalated in accordance with Bitkaya’s sanctions procedures.
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.
Where a sanctions alert is confirmed as a true match, Bitkaya shall immediately take the legally required restrictive measures, including blocking or freezing the relevant relationship, transaction, or assets where applicable. 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.
All sanctions alerts, reviews, outcomes, restrictive measures, and reports must be documented and retained in accordance with Bitkaya’s recordkeeping requirements.

5 Risk Profiling — Dynamic, EWRA-Based Classification

Each client is assigned a residual risk score based on Bitkaya’s Enterprise-Wide Risk Assessment (EWRA) model.

The model considers factors including:

client type, ownership structure, and PEP exposure;
onboarding method;
geographic and jurisdictional exposure;
nature of products and services used;
transactional behaviour; and
delivery channel, including remote versus face-to-face interaction.

The resulting risk rating determines the depth of due diligence, frequency of review, intensity of transaction monitoring, escalation thresholds, and any enhanced control measures required during onboarding or throughout the client relationship.

Within a building block the highest applicable score is always chosen. For example, a client engaging in simple fiat transfers via a local bank, but trades more than Cg. 30.000, gets a risk score of 3 (not 1) on Product & Behavioral Risk.

Fiat Red Flags:

Transaction Structuring / Smurfing (multiple small deposits within a short time frame to avoid detection thresholds)
Sudden Activity Spikes (large trades inconsistent with history)
Unknown Deposit Origin (deposit from bank account not in the name of client)
Any other red flags as indicated by the compliance officer from time to time

Onchain Monitoring:

Crypto transaction monitoring provider scans non-custodial client wallets against over 20 different risk sources (e.g. mixer/tumbler usage, sanctions exposure, stolen coins, scam proceeds, ransomware/extortion, terrorism financing, child exploitation content, darknet markets, high-risk exchanges, P2P platforms, and obfuscation smart contracts).
Provider assigns proprietary crypto risk score of 0-25% (minimal risk), 25-75% (moderate caution advised) and >75% (strongly advice to reject).

Application of the Risk Scoring Model leads to a Risk Classification, which is formally documented as:

Initial Risk Classification (onboarding)
Recurring Risk Classification (periodic review, or red flag/transaction monitoring trigger-based)

Risk Classification is prepared by Operations. In case of onboarding, the Risk Classification is compared to the Preliminary Risk Assessment that followed from the Data Collection phase. Any discrepancies are clearly indicated.

6 Customer Due Diligence (CDD) Levels

Bitkaya distinguishes between low-risk, medium-risk, and high-risk clients and applies due diligence measures proportionate to the assessed level of risk.

Low-Risk Clients

Simplified Due Diligence may only be applied where the client has been assessed and documented as low risk. The file must still contain sufficient information to establish identity, understand the purpose and intended nature of the relationship, confirm screening outcomes, and support the risk classification.

Low-risk clients are subject to periodic review at least once every three years.

Medium-Risk Clients

Standard Due Diligence applies. Bitkaya collects sufficient information to establish identity, understand expected activity, assess source of funds at least on a self-declaration basis, and monitor the relationship using risk-appropriate controls.

Medium-risk clients are subject to periodic review at least once every two years.

High-Risk Clients

Enhanced Due Diligence applies. Additional information, documentation, and review must be obtained sufficient to understand the client’s ownership, control, source of wealth, source of funds, activity profile, counterparties, and transactional behaviour.

High-risk clients are subject to periodic review at least once every year, and enhanced monitoring and escalation thresholds apply throughout the relationship.

No high-risk client may be approved before source of wealth has been assessed.

7 Transaction Monitoring — Behaviour-Based Surveillance

Bitkaya applies behaviour-based transaction monitoring across fiat and virtual asset activity to identify unusual, suspicious, or inconsistent conduct.

Monitoring includes review of:

large or unusual transactions;
repeated smaller transactions that may indicate structuring;
sudden changes in transaction size, velocity, or pattern;
activity inconsistent with the client’s known profile or expected behaviour;
unusual routing of funds or assets;
exposure to higher-risk wallets, services, typologies, or counterparties;
suspicious off-ramping or on-ramping behaviour; and
wallet links to sanctions exposure, darknet markets, mixers, stolen assets, fraud typologies, ransomware, terrorism financing, or other elevated-risk indicators.

For higher-risk activity, Bitkaya may apply additional controls such as enhanced review, transaction limits, additional supporting documentation, temporary holds, or escalation to Compliance.

As a practical rule of thumb, tracing depth should ordinarily extend sufficiently to understand the relevant source and destination profile of funds or assets. In escalated or higher-risk cases, enhanced tracing may extend materially further where necessary to support a reasonable compliance conclusion. The level of tracing performed and the rationale for any conclusion reached must be documented.

8 Ongoing Monitoring

Transaction Monitoring: Automated blockchain monitoring tools detect high-risk transfers (e.g., mixers/tumblers, darknet wallet interactions).
Periodic Review:
- Low-risk: every 3 years.
- Medium-risk: every 2 years.
- High-risk: annually or whenever significant red flags arise.
Sanctions & PEP Screening: Continuous screening against UN, OFAC, EU, and CFATF lists.
In addition to periodic file reviews, ongoing monitoring includes sanctions-list refresh screening, relevant transaction- or wallet-level screening where required by the control framework, and trigger-based reassessment where red flags, material changes, or unusual activity arise.

9 Suspicious Activity Reporting

Bitkaya maintains a documented internal escalation and case-handling process for unusual or suspicious matters identified through onboarding, sanctions screening, transaction monitoring, staff escalation, or other control activities.
For internal purposes, Bitkaya may use case classifications such as SAR, STR, FFR, or PNMR to support review, prioritization, escalation, and recordkeeping.
For external purposes, Bitkaya reports to the FIU Curaçao exclusively through a Unusual Transaction Report (UTR), where reporting is required.
All internal escalation steps, review decisions, supporting analysis, and external reporting outcomes must be documented and retained in accordance with Bitkaya’s recordkeeping framework.

10 Record-Keeping

All KYC files, customer profiles, blockchain wallet analytics, and transaction records must be stored securely for at least 5 years.
Digital records must be encrypted, with strict access controls.
Records should be easily retrievable for audits, compliance reviews, and regulator inspections.

11 Training & Awareness

Annual AML/KYC Training for all employees, including case studies on crypto-related financial crime.
Specialized Training for onboarding, risk, and compliance teams on blockchain forensics tools (e.g., Chainalysis, Elliptic).
Awareness Initiatives to reinforce vigilance, e.g., newsletters on emerging ML/TF risks in crypto markets.

12 Governance & Oversight

Board of Directors: Approves policies and receives quarterly compliance updates.
Compliance Officer (MLRO): reviews CDD/KYC implementation, reports to FIU, ensures alignment with FATF guidance.
Internal Audit: Conducts independent reviews of KYC/CDD effectiveness and regulatory compliance.

13 Proportionality Implementation

13.1 Purpose and Rationale

Bitkaya’s approach to proportionality ensures that the KYC and Customer Due Diligence (CDD) framework remains risk-based, scalable, and fit-for-purpose in line with CBCS guidance and the FATF’s expectations for smaller VASPs.

As a startup-stage institution, Bitkaya applies AML/CFT controls proportionate to its size, complexity, and risk exposure. This means implementing simplified but effective procedures for KYC, transaction monitoring, and sanctions screening — without compromising on the integrity or effectiveness of financial crime prevention.

The principle of proportionality ensures that all due diligence processes meet the minimum regulatory standards under Curaçao’s National Ordinances (NOIS, NORUT, NOSVASP) while remaining operationally feasible for a small VASP. This enables the company to grow responsibly while maintaining full compliance.

13.2 Guiding Principles

Bitkaya applies proportionality on a documented risk basis. Simplified measures are not applied automatically solely because a client, legal entity, or counterparty is regulated or established in a particular jurisdiction. Any reduced control approach must be justified by the documented risk assessment and remain consistent with applicable law and supervisory expectations.

13.3 Governance and Oversight

Board of Directors: Approves the proportional KYC/CDD framework and ensures that resource allocation and staffing remain adequate for Bitkaya’s risk profile.
Compliance Officer (MLRO): Oversees proportionality assessments, maintains the CDD risk matrix, and ensures that simplified measures do not create residual risks.
Internal/External Audit: Reviews proportionality justifications, testing that simplified CDD processes remain effective and that risk thresholds are correctly applied.
Management and Staff: Implement and document all proportional controls, ensuring auditability and traceability within Bitkaya’s compliance management system.

13.4 Proportional Application Across KYC/CDD Domains

Proportionality is reflected in the depth of file requirements, source of funds or source of wealth review, screening intensity, KYV measures, and frequency of review. Low-risk clients may be subject to simplified measures only where their low-risk status has been assessed and documented. Medium-risk and high-risk clients are subject to progressively stronger controls, evidence requirements, monitoring measures, and approval thresholds.

External FIU reporting remains centralized through the UTR process under the responsibility of the Compliance function / MLRO.

13.5 Documentation and Audit Trail

All proportionality determinations are formally documented and include:

Justification for simplified or enhanced CDD.
Reference to applicable CBCS and FATF guidance.
Risk-based rationale supported by EWRA scoring.
Board or Compliance approval record.

These records are retained for five years and are available for regulatory review by CBCS or FIU Curaçao upon request.

13.6 Continuous Improvement and Scalability

Proportionality is re-evaluated during Bitkaya’s annual compliance review and upon any significant operational change (e.g., customer base expansion, product introduction, or system integration).

As the company matures:

Staffing, technology, and policies will scale accordingly.
Manual controls will transition to automated, integrated compliance workflows.
CBCS feedback and external audit results will directly inform proportionality adjustments.

14 Prohibited Relationships and Restricted Counterparties SOP

14.1 Purpose

This SOP explains which clients, counterparties, and relationships Bitkaya must not onboard, must restrict, or must escalate before proceeding.

Its purpose is to give staff a practical rule set for cases where the relationship itself is unacceptable or where enhanced review is required before Bitkaya may continue.

Bitkaya applies this SOP on a proportional basis. As a small VASP, the company does not need a complex prohibited-relationships framework, but it does need a clear list of relationships that are not acceptable and a simple escalation path for restricted cases.

14.2 Scope

This SOP applies to:

prospective clients;
existing clients under review;
beneficial owners and controlling persons;
relevant VASP counterparties;
introducers, agents, and other third parties where financial-crime risk is relevant; and
requests to re-enter a relationship after a prior financial-crime exit.

14.3 Basic Rule

If a relationship falls into a prohibited category, Bitkaya must not onboard it and must not continue it.

If the case falls into a restricted category, the relationship may only proceed after the required escalation and approval.

Commercial importance is not a reason to bypass this SOP.

14.4 Prohibited Relationships

Bitkaya must not onboard or maintain relationships where any of the following apply:

anonymous or fictitious clients;
clients whose identity cannot be adequately verified;
shell banks;
unlicensed or unregulated financial institutions or remittance businesses where licensing or registration is required;
parties that Bitkaya knows are acting for or providing services to shell banks in a prohibited manner;
sanctioned persons or entities;
blocked or frozen parties where law or sanctions rules prohibit dealing;
clients or counterparties using Bitkaya for clearly unlawful purposes;
clients previously exited for financial-crime reasons unless re-entry is formally approved under Section 14.7;
any relationship that Bitkaya cannot lawfully maintain under applicable Curaçao, CBCS, sanctions, or AML/CFT requirements.

14.5 Restricted Relationships

The following are not automatically prohibited, but they are restricted and must be escalated before proceeding:

higher-risk VASPs or counterparties in weaker-control jurisdictions;
PEP-linked or politically exposed structures, where the case is not prohibited but higher risk;
clients or counterparties with serious adverse media or integrity concerns;
unusually opaque ownership structures;
relationships involving higher-risk sectors, intermediaries, or transactional behavior;
cases where identity is verified but the rationale, source of funds, wallet provenance, or expected activity remains unclear;
re-entry requests from previously offboarded or rejected clients.

14.6 What Staff Must Do

When a potential prohibited or restricted relationship is identified, staff must:

stop the onboarding or review process from progressing normally;
document the reason for concern;
preserve any supporting records or screening results; and
escalate to Compliance.

Staff must not override the issue informally.

14.7 Re-Entry After Prior Exit

If a client or related party previously exited, was rejected, or was restricted for financial-crime reasons, the case must not be treated as a normal new onboarding.

Before any re-entry may be considered:

the prior exit reason must be identified;
Compliance must review the file;
any new information must be assessed;
the reason the risk is considered changed must be documented; and
Senior Management must approve before onboarding may proceed.

If the prior reason remains unresolved or the risk is still unacceptable, Bitkaya must refuse the relationship.

14.8 Approval Rules

14.8.1 Prohibited cases

No approval may override a genuinely prohibited relationship.

14.8.2 Restricted cases

Restricted cases require at least:

business owner input; and
Compliance approval.

Senior Management approval is required where:

the case involves re-entry after prior exit;
the case is high risk or commercially sensitive;
there are serious integrity concerns; or
the decision may materially affect Bitkaya’s financial-crime risk profile.

14.9 Minimum File Evidence

The file should contain, where relevant:

screening results;
identity / ownership information;
summary of the restriction or prohibition trigger;
Compliance review note;
approval or rejection outcome; and
re-entry rationale, if applicable.

A short but clear file is sufficient at Bitkaya’s current scale.

14.10 Ongoing Review

This SOP also applies to existing relationships where new information appears, including:

sanctions alerts;
adverse media;
ownership changes;
law-enforcement or regulatory concerns;
suspicious activity findings; or
concerns that the client or counterparty now falls within a prohibited or restricted category.

If that happens, the relationship must be reviewed promptly and may need to be paused, restricted, exited, or reported.

15 Bitkaya Sanctions Screening SOP

15.1 Purpose

This SOP explains the minimum sanctions screening steps Bitkaya must perform before onboarding a client, activating a relationship, processing relevant transactions, or continuing a relationship where sanctions risk may arise.

Bitkaya applies this SOP on a proportional basis. As a small VASP, the sanctions process should be centralized, tool-supported, practical, and auditable. Low-risk screening should be handled efficiently, but unresolved matches or sensitive cases must always be escalated.

15.2 Scope

This SOP applies to:

prospective clients;
existing clients;
beneficial owners and authorized persons, where relevant;
relevant VASP or other counterparties, where required;
wallet addresses and blockchain transfers, where screening is part of the control process; and
trigger events requiring re-screening.

15.3 Basic Rule

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.

15.4 When Screening Must Happen

Sanctions screening must happen at the following points:

15.4.1 Onboarding

Before a client or relevant party is approved.

15.4.2 Before activation / first transaction

Where applicable, before the relationship becomes operational.

15.4.3 Ongoing screening

Existing clients and relevant parties must be re-screened through the screening tool on an ongoing basis.

15.4.4 Trigger events

Re-screen when there is a:

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.

15.4.5 Transaction / wallet screening

Where Bitkaya screens wallet addresses or transfer activity, alerts must be reviewed before the transfer is treated as cleared.

15.5 What Must Be Screened

At minimum, Bitkaya should 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.

15.6 Lists and Data Sources

Bitkaya should use a sanctions screening tool that covers at least the main sanctions sources relevant to its business, including:

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.

15.7 Alert Handling

15.7.1 No alert

If there is no alert, the process may continue.

15.7.2 Possible or partial match

If the tool returns a possible match:

stop the process;
collect the relevant case details;
escalate to Compliance; and
do not onboard, activate, or release the transaction until cleared.

15.7.3 Confirmed match

If Compliance confirms a true match:

reject onboarding, or
freeze / block the relevant relationship or transaction, where applicable; and
follow Bitkaya’s escalation and reporting process.

15.8 Roles

15.8.1 Operations / Business

Operations or the relevant first-line user is responsible for:

ensuring screening is completed at the required stage;
not progressing unresolved alerts; and
escalating possible matches immediately.

15.8.2 Compliance

Compliance is responsible for:

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.

15.8.3 Senior Management

Senior Management only needs to be involved where the case is material, complex, or has wider business impact.

15.9 Recordkeeping

Bitkaya should retain enough evidence to show that sanctions screening happened and how alerts were resolved.

Minimum records should include:

screening result;
alert details, if any;
Compliance review notes;
final outcome;
freeze / reject decision where relevant; and
related reporting record where applicable.

A simple but clear record is sufficient, provided it can be retrieved later.

15.10 Tool Refresh and Failures

The screening tool should refresh sanctions data automatically.

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.

15.11 Review and Testing

Compliance should periodically review whether:

screening is happening at the correct stages;
alerts are resolved on time;
records are complete; and
list coverage and tool settings remain appropriate.

A lean control review is sufficient at Bitkaya’s current scale, but it must still be documented.

Implementing Procedures and Controls

Procedures

Controls

Source Document

Document title: Bitkaya KYC & CDD Manual
Version: 1.1
Status in source document: FINAL
Date in source document: April 2026
Approval evidence: the change log records Board approval for version 1.1 in April 2026
Approval-date basis: PDF metadata records 2026-04-21 and is used as the exact BCMS approval and effective date because the visible document gives no day
Permanent approved artifact: Bitkaya KYC & CDD Manual v11 Approved.pdf

Operating Layer

This policy is a specialized operating layer within PRC-FCI-001 Financial Crime and Integrity, implemented through PROC-KYC-001 through PROC-KYC-007 and CTRL-KYC-001 through CTRL-KYC-007.

The KYC objects specialize the AML procedures and controls without creating a subordinate Process object or replacing the broader AML framework.

Exceptions

No exception may override legal identification, sanctions, FIU reporting, recordkeeping or prohibition requirements. Any permitted risk-based simplification must be justified, approved and recorded.

Relationships

Related policy: POL-AML-001 AML CTF CPF Compliance Manual
Process: PRC-FCI-001 Financial Crime and Integrity

Assurance

Approved artifact reviewed: yes
Board approval captured: yes
Procedure and control decomposition completed: yes
Operating effectiveness assessed: no
Overall status: policy and control design implemented; operating-effectiveness testing remains required

History

2026-07-26: Created from the approved Bitkaya KYC & CDD Manual version 1.1.
2026-07-28: Enriched to full 100% PDF coverage — every section, paragraph, SOP and building block transcribed into the policy body.
2026-07-29: Added SRC-AML-001 (consolidated AML/CFT/CPF ordinance) to sources frontmatter; added PB 2026 nr. 35 reference for current CDD thresholds and high-risk jurisdiction lists (CHG-RES-001, CHG-RES-005).

BCMS

Explorer