AML CTF CPF Compliance Manual

Purpose

Represent Bitkaya’s approved AML/CTF/CPF Compliance Manual as the BCMS policy object governing virtual-asset AML, counter-terrorist financing and proliferation-financing controls.

Policy Statement

Bitkaya B.V. is committed to operating with integrity, transparency, and accountability in the delivery of virtual asset services. As a licensed Virtual Asset Service Provider (VASP) in Curaçao, Bitkaya fully adheres to the regulatory requirements. Bitkaya further aligns its internal controls and compliance framework with international AML/CFT best practices.

Bitkaya must maintain a documented, risk-based AML/CTF/CPF program for virtual asset activities that identifies, assesses, mitigates, monitors and reports relevant money laundering, terrorist financing and proliferation-financing risks.

The AML/CTF/CPF framework must support customer due diligence, KYT and KYV, sanctions screening, FIU reporting, Travel Rule compliance, recordkeeping, training, technology controls, independent testing and proportionate governance.

Scope

This policy applies to all entities, departments, systems, and personnel of Bitkaya B.V., including its client onboarding, service delivery, and financial operations. It governs Bitkaya’s compliance with anti-money laundering (AML), counter-terrorist financing (CTF), and sanctions obligations in all jurisdictions where it operates. The policy applies to all customer-facing and operational activities across Bitkaya’s virtual asset services.

Roles

Compliance owns the AML/CTF/CPF framework and supports the MLRO function. The Compliance function reports directly to the CEO and is responsible for ensuring that the organization consistently operates within the boundaries of laws, regulations, and internal policies. Compliance is proactive and continuous, embedding regulatory awareness and ethical practices into daily business operations.
Operations executes client-facing screening, onboarding, monitoring and recordkeeping steps.
Management and the Board approve material AML/CTF/CPF changes and review risk outcomes.
Independent review tests the design and operation of the framework on a risk basis. Bitkaya’s AML/CFT policies and procedures are independently tested by Bitkaya’s internal audit personnel or competent external sources focusing on objectively assessing processes, controls, and risk management frameworks to verify that compliance measures are effective and that resources are safeguarded. By keeping Compliance and Audit as separate but complementary functions, the organization strengthens its governance framework, ensures accountability, and reinforces the integrity of its operations.

Manual Summary

The approved manual covers:

Policy statement and internal control expectations
Scope and regulatory framework
Risk-based approach and EWRA / SARA alignment
CDD, KYT and KYV
Sanctions screening and prohibited jurisdictions
FIU reporting and internal case classification
Travel Rule compliance
Recordkeeping and data retention
AML/CFT training and awareness
Technology and systems controls
Independent review and testing
Policy management and review
Client acceptance SOPs
Wallet ownership verification SOPs
Proportionality implementation

1 AML Policy Statement

1.1 Commitment to Formal System of Internal Control

Bitkaya applies a formal system of internal control:

Enterprise-Wide Risk Assessment
Risk profiling of clients
Customer Due Diligence and Enhanced Due Diligence
Transaction monitoring
Counterparty due diligence
Reporting of unusual transactions
Screening and freezing procedures under applicable sanctions lists
Adequate recordkeeping of clients and transactions

1.2 Compliance & Audit Function

The Compliance function, reporting directly to the CEO, is responsible for ensuring that the organization consistently operates within the boundaries of laws, regulations, and internal policies. Compliance is proactive and continuous, embedding regulatory awareness and ethical practices into daily business operations.

Bitkaya’s AML/CFT policies and procedures are independently tested by Bitkaya’s internal audit personnel or competent external sources focusing on objectively assessing processes, controls, and risk management frameworks to verify that compliance measures are effective and that resources are safeguarded.

By keeping Compliance and Audit as separate but complementary functions, the organization strengthens its governance framework, ensures accountability, and reinforces the integrity of its operations.

1.3 HR Implementation

Compliance with all AML/CFT laws and regulations is the responsibility of every employee, therefore:

Personnel is appropriately screened before entering into employment
Provided training to increase AML/CFT knowledge and awareness is mandatory

1.4 Review and Maintenance

This policy statement, and all associated AML/CFT policies and procedures, are reviewed at least annually or upon:

Changes in law or regulation
Material changes in Bitkaya’s business model
Findings from internal audits, regulators, or external assessments

2 Scope & Regulatory Framework

2.1 Scope

2.2 Regulatory Framework

Bitkaya’s AML/CFT compliance framework is grounded in the following legal and regulatory sources:

2.2.1 Curaçao Law

Code of the Criminal Law (Penal Code)
National Ordinance on the Reporting of Unusual Transactions (NORUT)
National Ordinance on Identification of Clients when Rendering Services (NOIS)
Sanctions National Ordinance and Kingdom Sanction Law
National Ordinance Supervision Virtual Asset Service Providers (NOSVASP)

2.2.2 Provisions and Guidelines

CBCS Procedures and Guidelines

2.2.3 International Standards

FATF 40 Recommendations
Global Digital Finance Standards and Codes

2.3 Supervisory Authority

Bitkaya operates under direct regulatory oversight of the Central Bank of Curaçao and Sint Maarten (CBCS).

3 Risk-Based Approach

3.1 Overview

Bitkaya B.V. applies a Risk-Based Approach (RBA) to all elements of its AML/CFT/CFP compliance program, in alignment with the FATF Recommendations, CBCS Provisions & Guidelines, and the Systematic AML/CFT Risk Assessment (SARA) model.

The RBA ensures that:

Resources are allocated in proportion to the risk of money laundering, terrorist financing, or sanctions evasion
Higher-risk clients, transactions, jurisdictions, or services are subject to enhanced scrutiny
Controls are calibrated based on the institution’s actual exposure to financial crime

3.2 Enterprise-Wide Risk Assessment (EWRA)

The EWRA is the foundation of Bitkaya’s risk-based AML/CFT program. It is conducted annually, or when material changes occur in:

Product and service offerings
Client base composition
Regulatory obligations or country risk profiles

The EWRA assesses inherent risk and control effectiveness across key domains:

Customer base
Nature of services and products
Geographic exposure
Delivery channels
Transactional behavior

Each domain is scored for inherent likelihood and impact, with control effectiveness applied to determine residual risk. The results inform:

Risk appetite alignment
CDD/EDD thresholds
Monitoring rules and alert tuning
Client segmentation and review cycles

3.3 CBCS SARA Framework Integration

Bitkaya’s EWRA and client-level assessments are fully aligned with the CBCS SARA methodology, which requires:

Systematic identification and documentation of risks
Evaluation of control adequacy and effectiveness
Prioritization of mitigation efforts based on residual risk levels
Ongoing update of risk ratings at both the enterprise and client levels

SARA emphasizes:

Formal scoring methods
Maintenance of a risk register
Independent testing of controls
Documentation of rationale and evidence for ratings

Bitkaya performs the Systematic AML/CTF/CPF Risk Assessment (SARA) at least annually and upon material trigger events. The SARA is documented, approved, retained, and used to calibrate Bitkaya’s AML/CTF/CPF risk-based control framework, including client risk scoring, CDD/EDD requirements, sanctions controls, transaction monitoring thresholds, training priorities, independent testing scope, and management reporting.

3.4 Client-Level RBA Application

Based on the EWRA model, Bitkaya assigns a residual risk score to each client. This risk rating determines:

The depth of CDD or need for EDD
Frequency of reviews
KYT monitoring thresholds
Escalation criteria for STRs and sanctions matches

3.5 Company-Level RBA Application

Based on the EWRA model, Bitkaya assigns an average residual risk score of the organization as a whole, and uses this to:

Design and calibrate its entire AML/CFT compliance framework
Inform internal policies, the allocation of compliance resources, structuring of procedures, and the formulation of thresholds and alerts
Maintain effective safeguards while avoiding overregulation of low-risk activities

3.6 Continuous Improvement

Risk assessment results are reviewed by:

The Compliance Officer/MLRO
The Compliance Committee (based on proportionality principle)
The Board of Directors

Adjustments are made to ensure the program remains aligned with emerging risks, CBCS expectations, and Bitkaya’s risk appetite.

Trigger events requiring SARA review or update include, where relevant, material changes in Bitkaya’s business model, products, services, client base, jurisdictions, transaction volumes, delivery channels, wallet arrangements, outsourcing or technology arrangements, regulatory requirements, sanctions exposure, typologies, significant incidents, internal control findings, independent testing results, CBCS or FIU feedback, or other material changes affecting AML/CTF/CPF risk.

4 Customer Due Diligence (CDD) Process

4.1 Overview

Bitkaya’s Customer Due Diligence (CDD) program is a central pillar of its AML/CFT compliance framework, designed to identify, assess, and mitigate financial crime risks throughout the client lifecycle. The CDD process is structured around four interdependent components: KYC/KYT/KYV, Sanctions Screening, Risk Profiling, and Transaction Monitoring. Together, these pillars form a comprehensive, risk-based system that ensures both regulatory compliance and effective risk management.

4.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:

KYC (Know Your Customer): Bitkaya verifies each client’s identity at onboarding using a third party digital ID verification tool. Individuals must upload a valid passport, identity card (cédula), or a driving license and complete a liveness test. For legal entities, Bitkaya collects and reviews documentation sufficient to establish the entity’s legal existence, authorized representatives, and beneficial ownership. These steps ensure that only verifiable and transparent clients are permitted to access Bitkaya’s services.
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, pattern, destination, source, exposure to higher-risk wallets or services, suspicious wallet connections (e.g. mixers, darknet exposure), and consistency with known client information. Alerts are generated for further review or escalation.
KYV (Know Your VASP): Counterparty due diligence is applied to all relevant VASP relationships. KYV helps prevent indirect exposure to illicit actors through VASP-to-VASP transfers or routing of assets. The extent of KYV measures is determined on a documented risk basis.

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

License and/or information about the regulatory supervisor
Company registry extract
Certificate of incorporation (or other appropriate certificate of registration or licensing)
Ownership and control information where relevant
Sanctions screening results
Independent data sources, including electronic sources, e.g. business information services

4.3 Sanctions Screening – Ongoing Exposure Management

Bitkaya performs sanctions screening as a mandatory control before onboarding, before activation of a relationship, during periodic review, upon relevant trigger events, when sanctions lists are updated or refreshed, and before execution, settlement, release, or completion of any relevant transaction.

Sanctions screening is not limited to the client and beneficial owner. Depending on the relationship, transaction, payment flow, wallet setup, or counterparty structure, screening must include, at minimum where applicable:

the client
beneficial owner(s)
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

For transaction-related activity, Bitkaya must screen the relevant transaction counterparty before the transaction is executed, settled, released, or otherwise treated as cleared. This includes, where applicable, VASP counterparties, wallet addresses, blockchain identifiers, fiat payment counterparties and any other transaction-linked party that may create sanctions exposure.

Screening must be conducted using reliable screening tools, current sanctions data and documented procedures. At a minimum, screening must cover the United Nations and European Union sanctions lists. Where applicable to Bitkaya’s business, client base, counterparties, jurisdictions, payment flows or risk profile, screening must also cover OFAC, CFATF, Curaçao / Kingdom / local sanctions or restricted lists, and internal restricted-party or restricted-jurisdiction lists.

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, transaction, wallet setup, payment, transfer, settlement or release must not proceed until the alert has been appropriately resolved or escalated.

Where a sanctions alert is confirmed as a true match, Bitkaya must immediately take the legally required restrictive measures, including blocking, freezing, rejecting, refusing or otherwise restricting the relevant relationship, transaction, assets, wallet, payment or transfer where applicable. The matter must be escalated internally to Compliance without delay and handled in accordance with applicable legal, FIU Curaçao and CBCS reporting or notification requirements.

All sanctions screening results, alerts, reviews, escalation decisions, false-positive closures, restrictive measures, reports and supporting rationale must be documented and retained in accordance with Bitkaya’s recordkeeping requirements.

4.4 Risk Profiling – Dynamic, EWRA-Based Classification

Each client is assigned a residual risk score based on Bitkaya’s Enterprise-Wide Risk Assessment (EWRA) model, which considers factors such as:

Client type, ownership structure and PEP exposure
Onboarding method
Geographic and jurisdictional exposure
Nature of products/services used
Transactional behavior
Delivery channel (remote vs. face-to-face)

Risk Based Outcomes

This risk rating determines:

the depth of CDD or need for EDD
the frequency of reviews
KYT monitoring thresholds
escalation criteria for unusual transaction reporting and sanctions handling
any enhanced control measures required during onboarding or throughout the relationship

Geographic Risk – Prohibited Jurisdictions

Bitkaya distinguishes between high-risk jurisdictions and prohibited jurisdictions. Jurisdictions subject to comprehensive United Nations sanctions, European Union sanctions, applicable Kingdom sanctions measures, or any other sanctions regime that legally prohibits or materially restricts the provision of services shall not be treated merely as high-risk jurisdictions.

Such jurisdictions are classified as Prohibited Jurisdictions and are outside Bitkaya’s risk appetite.

Bitkaya shall not establish or maintain relationships, process transactions, provide wallet services, facilitate transfers, or otherwise provide services where doing so would violate applicable sanctions legislation or involve a prohibited jurisdiction.

Where a client, beneficial owner, counterparty, transaction, wallet, or relationship becomes associated with a prohibited jurisdiction, the matter must be escalated immediately to Compliance for assessment and implementation of any required restrictive measures, including blocking, freezing, refusal, termination, reporting, or notification obligations. Prohibited jurisdictions are not eligible for risk acceptance through enhanced due diligence, risk mitigation measures, or management approval where applicable sanctions laws prohibit the activity.

Fiat Red Flags

Examples of fiat-related red flags include:

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 or FATF Red Flag documentation from time to time

Onchain Monitoring Indicators

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 advised to reject).

SARA Risk Scoring Methodology

The SARA model distinguishes between individual risk-factor scores and the final client risk score.

Individual risk factors may show raw or residual scores above 25 where the factor represents a high-severity risk indicator, such as sanctions exposure, PEP exposure, cash activity, complex structures, fiat red flags or high-risk wallet exposure.

The final client risk score is not calculated as a simple sum of all raw scores and is not based solely on the highest individual risk factor.

The final client risk score is calculated as a weighted residual score across the main risk categories:

Geographical Risk
Customer Risk
Product Risk
Transaction Risk
Delivery Channel Risk

For each applicable factor, inherent risk is calculated by multiplying likelihood by impact. Residual risk is then calculated by applying the relevant control-effectiveness factor.

Applicable residual factor risks are aggregated by category and weighted according to the category weights in the SARA model.

The final weighted residual score determines the client risk rating, subject to documented Compliance judgement and any mandatory escalation, refusal, restriction, or prohibited-relationship rule.

Risk Rating Thresholds

Unless otherwise approved by Compliance and documented in the SARA methodology, Bitkaya applies the following rating thresholds:

Low Risk: final weighted residual score of 6 or below
Medium Risk: final weighted residual score above 6 and up to 12
High Risk: final weighted residual score above 12

Where the raw SARA output, final weighted residual score and final client classification differ materially, the rationale must be documented.

Risk Classification Process

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 trigger-based review)

Risk Classification is prepared by Operations. In the case of onboarding, the Risk Classification is compared to the Preliminary Risk Assessment completed during the Data Collection phase. Any discrepancies are clearly documented.

Risk Classification Outcomes

The scoring process distinguishes between low-, medium-, and high-risk clients and determines the required level of due diligence.

Low Risk (4–6 points): Simplified Due Diligence (SDD); review every three years.
Medium Risk (7–10 points): Standard CDD; review every two years.
High Risk (11–20 points): Enhanced Due Diligence (EDD); annual review.

The conflicting section 4.4 client risk thresholds are tracked in ISS-AML-001 Reconcile AML Manual Client Risk Rating Thresholds and must not be resolved by silently selecting one table.

High-Risk Client Requirements

High-risk clients (individual and corporate clients) are subject to Enhanced Due Diligence (EDD), require assessment of source of wealth before approval of the relationship, and are subject to more frequent reviews and stricter transaction controls.

Simplified Due Diligence (SDD) may only be applied where the client has been assessed and documented as low risk.

The minimum client file requirements applicable to each risk tier are set out in the tables below.

Table 1. Individual clients — minimum client file requirements by risk tier

Risk tier	Minimum client file requirements
Low risk	Valid passport, national identity card, or driver’s license; liveness / identity verification result; sanctions / PEP screening result; basic client profile; purpose and intended nature of the relationship
Medium risk	All low-risk items; plus proof of residence; source of funds information (self-declaration); additional information on expected transaction activity; adverse information review where relevant
High risk	All medium-risk items; plus source of wealth information and supporting documentation; enhanced source of funds review where appropriate; formal compliance and management approval before onboarding

Table 2. Corporate clients — minimum client file requirements by risk tier

Risk tier	Minimum client file requirements
Low risk	Recent corporate registry extract or equivalent registration document; signed UBO declaration; ID of authorized signatory / representative; sanctions / PEP screening results for the entity, authorized signatory, and declared UBOs; purpose and intended nature of the relationship
Medium risk	All low-risk items; plus articles of incorporation; shareholder register or equivalent ownership document; source of funds (self-declaration); additional information on expected transaction activity; adverse information review where relevant
High risk	All medium-risk items; plus enhanced ownership and control documentation for all relevant layers; verified source of wealth / source of funds information; formal compliance and management approval before onboarding

4.5 Transaction Monitoring – Behavior-Based Surveillance

Bitkaya’s transaction monitoring framework is designed to identify unusual or suspicious activity across both fiat and virtual asset activity. Monitoring is not limited to large or high-value transactions. It also includes patterns of repeated smaller transactions, structuring, velocity anomalies, unusual routing, and activity inconsistent with the client’s expected behavior or profile.

Monitoring scenarios and review criteria shall, where relevant, include:

structuring or smurfing through linked smaller transactions
sudden spikes in activity or value
transactions inconsistent with the client’s known profile, source of funds, or source of wealth
unusual use of multiple wallets, chains, or counterparties
exposure to high-risk wallets, services, or typologies
unusual on-ramping or off-ramping behavior, including higher-risk banking-rail usage

Bitkaya recognizes that both on-ramp and off-ramp transactions, including incoming and outgoing fiat and virtual asset flows, can present elevated ML/TF/PF risk. Higher-risk activity is therefore subject to practical, risk-based controls such as transaction limits, additional review, and escalation to Compliance where appropriate.

Thresholds, rules, and alert scenarios shall be calibrated by risk category and may include transaction limits, heightened review steps, or other risk-commensurate controls for higher-risk clients, products, jurisdictions, services, or transaction types.

All alerts must be reviewed by appropriately trained personnel. Escalation decisions, investigation steps, outcomes, and any related reporting action must be documented clearly.

Bitkaya applies a risk-based approach to blockchain tracing depth as part of transaction monitoring and enhanced due diligence. As a general rule of thumb, case-specific review will usually involve tracing up to three (3) hops, while high-risk or escalated cases may involve deeper tracing, often up to six (6) hops. The actual depth of tracing will depend on the blockchain involved, the capabilities of the relevant tools, and the usefulness of additional tracing in the circumstances of the case. This approach applies to targeted case review and enhanced investigation. It does not limit Bitkaya’s broader wallet monitoring tools, which may already incorporate exposure analysis across deeper transaction paths or broader network-level indicators as part of automated monitoring.

5 FIU Reporting Process

5.1 Overview

Bitkaya’s Financial Intelligence Unit (FIU) reporting process is structured to ensure timely and accurate reporting of suspicious activity, sanctions matches, and unusual transactions in accordance with the requirements of FIU Curaçao and the CBCS AML/CFT guidelines. The reporting process spans three critical compliance domains: Client Onboarding, Sanctions Screening, and Transaction Monitoring (KYT).

5.2 Internal Case Classification

Bitkaya may internally classify cases as SAR (Suspicious Activity Report), STR (Suspicious Transaction Report), FFR (Fund Freeze Report), or PNMR (Partial Name Match Report) for case handling, escalation, and recordkeeping purposes. These classifications are internal only. For external purposes, Bitkaya reports to the FIU Curaçao exclusively through a UTR (Unusual Transaction Report), in the prescribed format and through the prescribed channel. Internal classifications therefore do not represent separate external reporting categories, but only internal labels used to structure Bitkaya’s compliance review and reporting workflow.

5.3 Client Onboarding

During onboarding, if the customer presents suspicious documentation, behavior, or risk factors inconsistent with their profile:

Operations requests Compliance to initiate internal review based on the triggers and based on this collects additional documentation if required within 10 days
If warranted based on the collected information, a Unusual Transaction Report (UTR) is submitted to the FIU Curaçao within 24 hours

5.4 Sanctions Screening

Sanctions screening applies to onboarding, ongoing monitoring, and relevant transactions, using real-time or regularly refreshed list-matching tools.

Where a sanctions alert is confirmed as a true match, Bitkaya shall:

immediately apply legally required restrictive measures, including blocking or freezing where applicable
escalate the matter internally to Compliance without delay
assess and execute applicable external reporting obligations, including to the FIU Curaçao
assess and execute applicable notification or reporting obligations to the CBCS
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
operational freezing or blocking measures

The MLRO or designated Compliance Officer is responsible for coordinating these steps and ensuring that a complete record is maintained.

5.5 KYT / Transaction Monitoring

Bitkaya’s transaction monitoring system analyzes behavioral patterns across both crypto and fiat transactions. If suspicious behavior or inconsistencies are identified, an Unusual Transaction Report (UTR) is submitted to the FIU Curaçao.

5.6 Temporary Holds, Refusals and Restrictions for Suspicious Activity

Where unusual or suspicious activity is identified through onboarding, sanctions screening, transaction monitoring, wallet review, staff escalation, adverse information, or any other control activity, Bitkaya may temporarily pause, hold, refuse, restrict, or decline a client relationship, transaction, payment, transfer, settlement, wallet setup, or release while Compliance reviews the matter.

This may apply where there are unresolved concerns relating to money laundering, terrorist financing, proliferation financing, sanctions evasion, fraud, false or inconsistent information, unexplained source of funds, suspicious wallet exposure, third-party payments, unusual transaction behavior, or other material financial-crime concerns.

The purpose of a temporary hold or restriction is to prevent Bitkaya from executing, settling, releasing, or continuing activity where unresolved financial-crime concerns remain. The measure must be proportionate to the risk, documented, and escalated to Compliance without delay.

Compliance shall review the available information and determine whether the matter can be cleared, requires additional information, requires enhanced due diligence, should be refused or restricted, should be escalated to Senior Management, or should be assessed for external reporting to FIU Curaçao and/or CBCS.

Where a transaction or relationship is subject to review, staff must avoid tipping off the client or any unauthorized person. Client communication must remain factual, limited, and consistent with Bitkaya’s legal and regulatory obligations.

All temporary holds, refusals, restrictions, escalation decisions, investigation steps, outcomes, client communications, and any related FIU Curaçao or CBCS reporting or notification actions must be documented clearly.

5.7 Reporting Principles

All reports are filed by the MLRO or delegate
Submissions are made through the FIU Curaçao secure reporting portal
Documentation includes all internal notes, alerts, and escalation records
Reports are filed without delay upon determination of suspicion

This structured reporting process ensures that Bitkaya remains fully compliant with its statutory obligations while effectively mitigating financial crime risk.

6 Travel Rule Compliance

6.1 Purpose and Scope

This manual outlines Bitkaya’s policies and procedures to comply with the FATF’s Recommendation 16, commonly known as the “Travel Rule.” The Travel Rule mandates that certain information about the originator and beneficiary of a transaction “travels” with the transfer, enhancing transparency and aiding in the prevention of money laundering and terrorist financing.

6.2 Applicability of the Travel Rule

The Travel Rule applies to virtual asset transfers involving client funds when:

The transaction is between Bitkaya and another VASP.
The transaction is between Bitkaya and another obliged entity, such as a financial institution.

For transactions involving unhosted wallets (wallets not managed by a VASP or financial institution), the FATF does not require VASPs to submit collected Travel Rule information to the unhosted wallet. However, as a risk mitigation measure, Bitkaya should collect the required originator and beneficiary information from its own customer.

6.3 Information Requirements

For virtual asset transfers equal to or exceeding USD/EUR 1,000, Bitkaya must collect and transmit the following information:

Originator Information:

Full name
Account number or unique transaction identifier
Physical address, national identity number, customer identification number, or date and place of birth

Beneficiary Information:

Full name
Account number or unique transaction identifier

For transactions below the threshold, Bitkaya should collect and retain basic information as per its risk-based approach.

6.4 Data Collection and Verification

Know Your Customer (KYC): Implement robust KYC procedures to verify the identities of originators and beneficiaries.
Data Accuracy: Ensure the collected information is accurate and up-to-date.
Record Keeping: Maintain records of the required information.

6.5 Secure Data Transmission

Encryption: Utilize secure encryption methods to transmit information to beneficiary institutions.
Protocols: Adopt standardized protocols like the InterVASP Messaging Standard (IVMS 101) to facilitate interoperability.
Third-Party Solutions: Leveraging Travel Rule compliance solutions that support secure data sharing.

6.6 Counterparty Due Diligence

VASP Verification: Before initiating transfers, verify that the counterparty is a registered and compliant VASP.
Risk Assessment: Assess the jurisdiction and compliance status of counterparties, especially in regions with partial or no Travel Rule implementation.
Ongoing Monitoring: Continuously monitor counterparties for changes in compliance status.

6.7 Dealing with Unhosted Wallets

For transactions involving unhosted wallets:

Information Collection: Collect the required originator and beneficiary information from Bitkaya’s own customer.
Risk Mitigation: Apply enhanced due diligence measures, such as verifying the identity of the unhosted wallet owner, when appropriate.
Record Keeping: Retain all relevant information for such transactions, making it available to authorities upon request.

6.8 Whitelisting and Ownership Verification of Non-Custodial Wallets

6.8.1 Policy Overview

Bitkaya permits transactions involving non-custodial wallets only after verifying and whitelisting these wallets to ensure they are owned and controlled by the client. This policy aligns with FATF Recommendation 16 and guidance from jurisdictions like Switzerland, the EU, and Singapore, which emphasize the importance of verifying ownership of self-hosted wallets.

6.8.2 Verification Procedures

Clients must complete one of the following verification methods to whitelist a non-custodial wallet on a risk-based basis:

a. Self Declaration

The customer declares that he owns the address.

b. Message Signing

Clients sign a unique, Bitkaya-provided message using their wallet’s private key. This method is compatible with wallets supporting message signing, such as MetaMask, Ledger, Trezor, and WalletConnect. The signed message is then submitted to Bitkaya for verification.

c. Satoshi Test

Clients send a small, specified amount of cryptocurrency from their non-custodial wallet to a Bitkaya-designated address within a set timeframe. Successful receipt confirms wallet ownership.

d. Address Ownership Proof Protocol (AOPP)

Utilizing AOPP, clients can prove wallet ownership through a streamlined process involving QR codes or links, facilitating automatic verification without exposing private keys.

6.8.3 Whitelisting Process

Upon successful verification:

The wallet address is added to the client’s whitelist.
Future transactions to or from this address are permitted without additional verification.

If verification fails or is incomplete, transactions involving the wallet are prohibited.

6.8.4 Ongoing Monitoring and Reassessment

Bitkaya conducts periodic reviews of whitelisted wallets to ensure continued compliance. Clients may be required to re-verify ownership if:

There are significant changes in transaction patterns.
Regulatory requirements evolve.
Security concerns arise.

6.9 Data Protection and Privacy

All verification data is handled in accordance with Bitkaya’s Data Protection and Privacy Policy, ensuring confidentiality and compliance with applicable data protection laws.

7 Recordkeeping and Data Retention

7.1 Overview

Bitkaya B.V. maintains a robust recordkeeping and data retention framework as an integral part of its AML/CFT compliance program. This framework is designed to meet the requirements of the CBCS, law and relevant international standards.

7.2 Purpose

The purpose of Bitkaya’s recordkeeping and retention procedures is to:

Ensure complete and auditable documentation of customer due diligence (CDD), risk assessments, transactions, and regulatory reporting
Facilitate effective supervision by regulatory authorities
Enable internal reviews, investigations, and independent audits
Support timely and accurate reconstruction of customer profiles and financial activity if required

7.3 What Bitkaya Retains

Bitkaya stores all records that are necessary to demonstrate compliance with AML/CFT obligations, including:

Record Type	Description
KYC and CDD Files	Identification documents, UBO declarations, proof of address, onboarding notes, etc.
Client Risk Assessments	Risk scores, profiling justifications, review history
Transaction Records	Fiat and crypto transaction logs, timestamps, wallet addresses, counterparties
Sanctions Screening Results	Matches, resolution outcomes, freezing actions
UTR Reports	Submitted reports, internal alerts, supporting documentation
Monitoring Logs (KYT)	Alerts, case reviews, and escalation notes
Compliance Decisions	Approvals, rejections, EDD files, onboarding committee minutes
Training and Staff Records	Attendance logs, course content, certifications

7.4 Retention Period

All client and transaction records must be kept for at least five (5) years from the end of the relationship or the last transaction, whichever is later. These records must be accessible so transactions can be reconstructed and provided to the Central Bank or other authorized bodies upon request.

If a transaction is reported to investigative authorities (such as the FIU, Public Prosecutor, or Police), records must instead be kept for ten (10) years if instructed by the FIU.

CDD information must also be retained for at least five (5) years after the end of the business relationship and made available to the Central Bank or other authorized bodies when required.

7.5 Security and Integrity

All records are stored digitally in Bitkaya’s secure compliance archive, integrated with the ERP system
Access is role-based and logged
Monthly backups are maintained and stored off-site
Audit trails are preserved to document every critical access, update, or deletion attempt

7.6 Review and Oversight

The Compliance Officer is responsible for overseeing the recordkeeping framework.
Internal audits are conducted at least annually to verify the integrity and completeness of records.
Bitkaya ensures that all retained data is available for inspection by the CBCS and FIU Curaçao upon request, without undue delay.

8 AML/CFT Training & Awareness

8.1 Overview

Bitkaya B.V. maintains a structured and role-specific AML/CFT training and awareness program designed to ensure that all employees understand their legal obligations, can identify red flags of financial crime, and know how to apply internal procedures effectively. This program is a core element of Bitkaya’s compliance framework and supports compliance with the applicable regulations.

8.2 Objectives of the Training Program

The purpose of Bitkaya’s training program is to:

Equip staff with knowledge to detect, prevent, and report money laundering, terrorist financing, and sanctions violations
Ensure familiarity with Bitkaya’s internal controls and reporting procedures
Promote a culture of compliance across the organization
Meet regulatory expectations for staff competence, testing, and awareness documentation

8.3 Who Must Be Trained

All staff involved in client onboarding, transaction processing, compliance, trading, and IT/security
Senior management and directors (to understand oversight responsibilities)
Third-party contractors or vendors with AML-related functions (as applicable)

8.4 Training Schedule

Type of Training	Frequency	Audience
AML Onboarding Training	Upon hire	All new employees
Annual Refresher Training	Once per year	All employees
Role-Specific Training	As needed or annually	Compliance, Trading, IT
Ad Hoc Updates	Upon policy/tool changes	Relevant departments

8.5 Training Topics

Training modules cover both legal/regulatory concepts and internal procedures, including:

Overview of AML/CFT/CFP laws and CBCS regulations
Understanding of money laundering and terrorist financing typologies
Customer Due Diligence (CDD), Enhanced Due Diligence (EDD), and Risk Profiling
Sanctions screening procedures and red flag indicators
STR/FFR/PNMR reporting obligations
Use of KYT tools, transaction monitoring systems, and alert handling
Escalation workflows and documentation standards

8.6 Delivery & Assessment

Training is delivered via a combination of e-learning, live sessions, and scenario-based workshops
Knowledge checks and quizzes are used to assess comprehension
Attendance and test results are logged in Bitkaya’s compliance system
Staff who fail to meet minimum comprehension thresholds must retake training

8.7 Documentation & Oversight

Training logs, course materials, and attendance records are retained
The Compliance Officer is responsible for designing, updating, and monitoring the training program
Training effectiveness is evaluated through audits, feedback, and incident reviews
Program is updated regularly to reflect new regulations, typologies, or internal policy changes

9 Technology & Systems Controls

9.1 Overview

Bitkaya B.V. employs a robust set of technology and systems controls to ensure the integrity, security, and effectiveness of its AML/CFT compliance operations. These controls are critical for automating risk detection, protecting sensitive data, and ensuring traceable decision-making across digital asset services. The framework aligns with regulatory guidance, and cybersecurity best practices.

9.2 Key Objectives

Ensure accurate, real-time risk identification (KYC/KYT/sanctions)
Automate key compliance processes to reduce human error
Maintain secure handling and storage of sensitive client data
Enable consistent auditability and escalation tracking

9.3 Core Technology Components

KYC/IDV Integration — Use of third-party tools for ID verification, biometric checks, and liveness detection
KYT & Wallet Risk Analytics
- Real-time blockchain risk scoring
- Automated wallet alerts based on mixer use, darknet exposure, or sanctions proximity
Sanctions Screening Tools
- Screening of relationships against sanctions lists
- Automatic refresh of list data
Case Management System (CMS)
- Tracks alerts, escalations, approvals, and STR/FFR/PNMR decisions
- Includes timestamps, roles, and resolution status for full traceability
ERP & Compliance Dashboard
- Centralized visibility into compliance KPIs, outstanding alerts, and risk exposure
- Supports internal reporting and audit prep

9.4 Security & Access Controls

Role-based access to compliance platforms
Multi-factor authentication (MFA) and encryption at rest and in transit
Tamper-proof audit trails for all compliance decisions
Regular data backups and off-site encrypted storage

9.5 Oversight & Review

Compliance Officer oversees system effectiveness and tool calibration
Systems are reviewed annually or upon major updates
Vendor due diligence is conducted for third-party tools

10 Independent Review & Testing

10.1 Overview

Bitkaya B.V. conducts regular independent reviews and testing of its AML/CFT/CFP compliance program to ensure its design, implementation, and controls are effective and aligned with regulatory expectations. This process supports compliance with CBCS Provisions & Guidelines and FATF Recommendation 18, which emphasize the need for independent audit functions within AML programs.

10.2 Objectives of Independent Testing

Validate the effectiveness of internal AML/CFT/CFP policies and procedures
Identify gaps, control weaknesses, or areas of non-compliance
Test the implementation of processes (e.g., onboarding, screening, monitoring, reporting)
Assess the adequacy of recordkeeping and escalation mechanisms
Ensure compliance with CBCS, FIU Curaçao, and FATF standards

10.3 Scope of Testing

Independent AML/CTF/CPF testing must assess whether Bitkaya’s policies, procedures, controls and risk-management framework are effective and comply with applicable requirements, including NOIS, NORUT, CBCS Provisions & Guidelines, sanctions obligations and Bitkaya’s internal manuals.

The testing must be risk-based, proportionate to Bitkaya’s size and business model, and must include sample testing where relevant. The scope includes, at minimum:

evaluation of Bitkaya’s AML/CTF/CPF manual(s), procedures and control framework, including sanctions screening
review of the most recent AML/CTF/CPF risk assessment, including EWRA/SARA methodology, annual performance, trigger-based updates and alignment between enterprise-level and client-level risk assessment
customer file review, including KYC/CDD, EDD, beneficial ownership, authorized representatives, source of funds, source of wealth, client acceptance decisions and approval requirements by risk category
interviews with employees who handle onboarding, transactions, monitoring, escalation or reporting, and with their supervisors where applicable
sample testing of unusual transactions and alerts, including transactions on or beyond applicable thresholds, internal escalation, investigation quality, decision rationale and compliance with internal and external reporting requirements
review of freezing, unfreezing, blocking, restriction, refusal and release decisions, including sanctions-related restrictive measures and supporting documentation
review of corrective actions taken based on the previous independent testing report, internal review findings, regulatory feedback or material control issues
review of the documented Know Your Employee / employee screening policy and related implementation evidence
review of transaction monitoring and escalation processes, including on-ramp and off-ramp monitoring, alert scenarios, thresholds, calibration, escalation, investigation and documentation
review of sanctions-list monitoring, list coverage, list refresh, alert handling, false-positive closure rationale, unresolved-alert stop controls, freezing of assets and sanctions-related reporting or notification process
review of FIU Curaçao UTR decisioning and reporting controls, including timeliness, completeness, rationale, confidentiality and anti-tipping-off controls
review of wallet screening, wallet ownership verification, blockchain analytics and transaction tracing practices, including handling of high-risk wallet exposure
review of VASP counterparty due diligence and KYV controls where relevant
assessment of the adequacy of record retention, audit trails and retrievability of client files, screening results, monitoring alerts, case records, UTR files, freezing records, escalation records and training records
review of AML/CTF/CPF training coverage, role-based training content, completion records and remediation of overdue or failed training
review of AML/CTF/CPF technology and systems controls relevant to onboarding, screening, transaction monitoring, case handling, reporting, access rights, audit logs, tool calibration, list refresh, change management and vendor oversight

The reviewer must document the scope, methodology, sample basis, limitations, findings, ratings, recommendations, management responses and remediation actions. Findings must be reported to Senior Management and the Board. Remediation actions must be assigned an owner, target date and status, and must be tracked to completion.

10.4 Who Conducts the Testing

Internal Audit Function (if available and operationally independent), or
A qualified external audit firm or AML consultant

The testing team must have no day-to-day involvement in compliance operations and must report findings directly to senior management or the board.

10.5 Frequency

Independent testing is conducted at least annually, or more frequently where required.
Additional reviews may be triggered by:
- Material changes in the business or services
- Regulatory inspection findings
- Major policy updates or technology upgrades

10.6 Reporting & Remediation

A formal review report is produced and submitted to the Compliance Officer, senior management, and Board of Directors
All findings are logged and tracked to resolution
High-priority issues are addressed through documented remediation plans, with clear owners and deadlines

11 Policy Management & Review

11.1 Overview

Bitkaya B.V. maintains a structured Policy Management and Review framework to ensure that all AML/CFT/CFP policies, procedures, and internal guidelines remain current, effective, and aligned with regulatory expectations. This framework ensures that compliance documentation reflects Bitkaya’s evolving risk profile, legal obligations, and operational realities.

11.2 Purpose

The purpose of policy management is to:

Maintain clear, accessible, and enforceable compliance documentation
Ensure that all staff operate in accordance with the latest legal and regulatory requirements
Enable timely updates in response to changes in laws, risks, or operational structure
Demonstrate to regulators that Bitkaya has a living and responsive compliance framework

11.3 Scope of Policy Management

Policies and procedures covered include (but are not limited to):

AML/CFT Program Charter
KYC, KYT, and KYV Policies
Sanctions Screening Policy
Risk Profiling and EDD Guidelines
STR/FFR/PNMR Reporting Procedures
Training & Awareness Program
Technology & System Controls
Recordkeeping, Governance, and Testing Frameworks

11.4 Review Frequency

Document Type	Review Frequency	Responsible Party
Core AML/CFT Policies	Annually	Compliance Officer (MLRO)
SOPs and Manuals	At least annually or upon material change	Department Heads / Compliance
Risk Assessments (EWRA, client scoring)	Annually or upon change	Compliance / Risk

This manual shall also be reviewed promptly following any regulator findings, supervisory examination feedback, or identified control gaps affecting Bitkaya’s AML/CFT/CPF framework. Where required, related subordinate manuals and SOPs shall be updated in parallel to maintain consistency across the compliance framework.

11.5 Review & Approval Workflow

Policy Drafting or Update — Initiated by Compliance or relevant function
Internal Review — Circulated for feedback (Legal, Risk, Operations)
MLRO Sign-Off — Ensures regulatory alignment and consistency
Board/Committee Approval — Final endorsement of high-level policies
Staff Communication — Updated policies shared with impacted staff
Version Control — Each policy is versioned and archived

11.6 Governance & Oversight

The Chief Compliance Officer (MLRO) is responsible for maintaining the master compliance policy library
All approved versions are stored securely, access-controlled, and backed up
Outdated or superseded versions are retained to support audits and regulatory requests

11.7 Continuous Improvement

Policies are informed by findings from:
- Internal audits and independent reviews
- Regulatory inspections and CBCS guidance updates
- Lessons learned from STRs, alerts, or incident investigations
Bitkaya continuously benchmarks its policy framework against FATF standards, CBCS Provisions, and Global Digital Finance principles

12 Standard Operating Procedure (SOP): Client Acceptance

12.1 Capture Lead from Bitkaya Website

Action: Automatically capture lead information submitted via the Bitkaya website.
Storage: Store lead details in the CRM under the “Leads” module.

12.2 Perform ID and Sanctions Check

Individual Client

Initiate Verification: Use AMLBot’s KYC/AML service to verify the prospect’s identity and screen against global sanctions lists.
Process:
- Create an applicant profile in AMLBot.
- Submit identification documents for verification.
- Await verification results, typically available within 2 minutes to 6 hours.
Documentation: Download and securely store the ID Verification Report in the prospect’s CRM file or escalate to Compliance immediately when sanctions hits are present.

Legal entity

Initiate Verification: Use Simplified.ID service to verify the legal entity’s identity and screen against global sanctions lists.
Process: Bitkaya will use the service only to screen company names and identifiers where relevant, director names, UBO names, related sanctions-screening query data.
Documentation: Download and securely store the Sanction Screening Report in the legal entity’s CRM file.

12.3 Convert Lead to Opportunity in CRM

Conversion: Upon successful verification, convert the lead into an opportunity within the CRM system.
Assignment: Assign the opportunity to the appropriate sales representative for follow-up.

12.4 Update Contact Record

Purpose of Relationship: Record the purpose and intended nature of the relationship in the client file.
Transaction Profile: Document the expected transaction behaviors, including volume and frequency.
Compliance Data: Record all compliance-related information, such as verification status and risk assessments.
File Upload: Attach the ID Verification Report and any other relevant documents to the prospect’s CRM profile.

12.5 Complete SARA Risk Profile

Assessment: Conduct a SARA (Systematic AML/CFT Risk Assessment) to evaluate the prospect’s risk level.
Documentation: Record the risk assessment results in the contact’s CRM record and upload the completed SARA form to their file.

12.6 Conduct Additional Background Checks (If Necessary)

Research: Perform supplementary background checks using search engines or AI tools to uncover any adverse information.
Compliance Ticket: Log any findings into a compliance ticket within the CRM for further review.

12.7 Add Bank Details to CRM (If Applicable)

Information Collection: Gather the prospect’s banking information, ensuring accuracy and completeness.
CRM Update: Enter the bank details into the appropriate fields within the CRM system.

12.8 Attach Appropriate Price Lists

Selection: Determine the correct pricing structure applicable to the prospect.
CRM Update: Attach the selected price list to the contact’s CRM record and ensure it’s reflected in the vendor price lists.

12.9 Wait for Client Acceptance

Approval: Onboarding may proceed only once the documentation and information required for the applicable client risk tier have been completed and reviewed. Low- and medium-risk clients require management approval. High-risk clients require both Management Approval and Compliance Approval before onboarding.
Sanctions Escalation: Where a sanctions alert remains unresolved, onboarding must not proceed until the alert has been resolved or appropriately escalated. Where a sanctions match is confirmed, Bitkaya shall follow the applicable sanctions escalation, restrictive measures, and FIU/CBCS reporting process before any onboarding decision is considered.
High-Risk Clients: For high-risk clients, source of wealth must be assessed before approval of the relationship.
Enhanced blockchain tracing: Where enhanced blockchain tracing is required, the file shall reflect whether standard or enhanced tracing was performed and the reasons for that approach.
CRM Update: Ensure that client acceptance status and client acceptance date are logged by the approving function before proceeding.

12.10 Grant Portal Access and Send Welcome Email

Tagging: Label the contact as a “Client” within the CRM.
Portal Access: Enable access to the client portal, which will automatically trigger the dispatch of a welcome email.

By adhering to this SOP, Bitkaya ensures a standardized and compliant approach to client onboarding, aligning with best practices in AML/KYC procedures.

13 Standard Operating Procedure (SOP): Wallet Ownership Verification Based on Client Risk Level

13.1 Purpose

To establish a standardized protocol for verifying the ownership of self-hosted cryptocurrency wallets by clients, ensuring compliance with Anti-Money Laundering (AML) and Know Your Customer (KYC) regulations. This SOP outlines verification methods tailored to client risk levels, balancing security requirements with user experience.

13.2 Scope

This procedure applies to all clients initiating transactions involving self-hosted wallets, including deposits and withdrawals, within the exchange platform.

13.3 Risk-Based Verification Framework

Clients are categorized into three risk levels — Low, Medium, and High — based on factors such as transaction volume, geographic location, and activity patterns. Verification methods are assigned accordingly:

Low-Risk Clients

Definition: Clients with minimal transaction volumes, operating in low-risk jurisdictions, and exhibiting standard activity patterns.
Accepted Verification Methods:
- Self-Declaration: Client affirms wallet ownership through a signed statement or checkbox during the transaction process.
- Visual Proof: Submission of a screenshot or video displaying the wallet interface with the relevant address and timestamp.
Considerations: These methods offer ease of use but provide lower assurance levels. They are suitable where regulatory requirements permit.

Medium-Risk Clients

Definition: Clients with moderate transaction volumes, operating in jurisdictions with emerging regulatory frameworks, or exhibiting atypical activity patterns.
Required Verification Methods:
- Digital Signature: Client signs a unique message provided by the exchange using their wallet’s private key. The exchange verifies the signature against the public address.
- Micro-Transaction (Satoshi Test): Client sends a nominal amount of cryptocurrency from the wallet in question to a designated address within a specified timeframe.
Considerations: These methods provide a higher level of assurance and are appropriate for clients with moderate risk profiles.

High-Risk Clients

Definition: Clients with high transaction volumes, operating in high-risk jurisdictions, or exhibiting suspicious activity patterns.
Mandatory Verification Methods:
- Digital Signature: Same as Medium-Risk Clients.
- Micro-Transaction (Satoshi Test): Same as Medium-Risk Clients.
- AML Wallet Monitoring Report: Prior to any transactions, an AML risk assessment report must be obtained for the client’s wallet address. This report should include risk scoring, exposure to illicit activities, and any associations with sanctioned entities.
Considerations: These rigorous methods are essential for mitigating risks associated with high-risk clients and ensuring adherence to stringent regulatory standards.

13.4 Implementation Guidelines

Client Risk Assessment: Conducted during the onboarding process and reviewed periodically. Factors include transaction behavior, geographic location, and source of funds.
Verification Process:
- Clients are informed of their risk category and the corresponding verification requirements.
- Verification methods are implemented prior to processing transactions involving self-hosted wallets.
Record Keeping: All verification records are securely stored for a minimum of five years, in compliance with regulatory mandates.
Continuous Monitoring: Client activity is monitored to detect changes in risk profile, prompting re-evaluation of verification requirements as necessary.

13.5 Compliance and Review

Regulatory Alignment: This SOP aligns with guidelines from the Financial Action Task Force (FATF) and other relevant regulatory bodies.
Periodic Review: The SOP is reviewed annually or upon significant regulatory changes to ensure ongoing compliance and effectiveness.

14 Proportionality Implementation

The principle of proportionality allows Bitkaya to maintain an effective, risk-based AML/CFT framework aligned with CBCS expectations while ensuring efficiency, accountability, and scalability. This approach embodies the FATF-recognized concept that small VASPs can be fully compliant and well-governed without overextending operational capacity, provided proportional controls are clearly documented, monitored, and reviewed.

14.1 Purpose and Rationale

Bitkaya B.V., as a small and startup-stage Virtual Asset Service Provider (VASP), applies the principle of proportionality to ensure that all AML/CFT controls, governance measures, and compliance processes are commensurate with the nature, size, and risk profile of the institution.

This approach is in line with:

The Landsverordening toezicht virtuele activa dienstverleners (2025), which requires integrity and risk-based operations proportionate to business size.
The CBCS SARA and Risk-Based Supervision frameworks, emphasizing scalable control measures.
FATF and CFATF expectations for smaller VASPs to implement proportionate and effective compliance programs without unnecessary administrative burdens.

The principle of proportionality does not reduce the company’s responsibility for compliance. Instead, it ensures that Bitkaya achieves full adherence to AML/CFT obligations through fit-for-purpose systems, lean governance, and risk-prioritized resource allocation.

14.2 Guiding Principles

Bitkaya’s proportionality framework is guided by the following principles:

Risk-Based Application — AML/CFT controls are applied based on the level of ML/TF risk rather than organizational size alone. Higher-risk services (e.g., wallet transfers or high-value virtual asset exchanges) receive enhanced monitoring and due diligence.
Scalability and Efficiency — Processes, documentation, and control structures are designed to scale with business growth. Core compliance tools (KYC, KYT, sanctions screening) are centralized and automated to minimize manual workload.
Practical Governance — Governance roles may be consolidated where appropriate (e.g., the Compliance Officer also serves as the MLRO), provided that checks and balances and escalation mechanisms are maintained.
Resource Optimization — Use of external providers for independent audit, transaction monitoring, and sanctions screening allows Bitkaya to meet CBCS standards without internal duplication of complex technical functions.
Continuous Alignment — The proportionality approach is reviewed annually or upon any material business change, regulatory update, or audit finding, ensuring that the AML/CFT framework evolves alongside operational growth.

14.3 Governance and Oversight

Board of Directors: Retains full accountability for the AML/CFT framework and for ensuring that proportional implementation does not weaken control effectiveness.
Compliance Officer / MLRO: Ensures proportional application of policies and reports on adequacy to the Board and CBCS.
Independent Reviewer: Conducts periodic reviews of proportionality justifications to ensure residual risks remain within acceptable limits.

Where functions are combined due to scale, compensating controls — such as independent audit or CEO-level oversight — are documented and approved by the Board.

14.4 Application of Proportionality Across AML/CFT Domains

a. Enterprise-Wide Risk Assessment (EWRA)

The EWRA process follows the CBCS SARA model but uses simplified quantitative scoring suitable for a startup structure.
Data-driven tools automate client and transaction risk classification.
Annual EWRA updates suffice unless there is a significant change in product scope, volume, or jurisdictional exposure.

b. Customer Due Diligence (CDD) and Enhanced Due Diligence (EDD)

Simplified CDD may only be applied where the client has been assessed and documented as low-risk. Even where SDD is applied, Bitkaya will still apply the core CDD measures appropriate to the client type and risk, including identifying the client, identifying the beneficial owner where applicable, understanding the purpose and intended nature of the relationship, and conducting ongoing monitoring. The extent of documentation and verification required is determined on a risk-based basis.
EDD applies only where objective indicators (PEP, high-risk jurisdiction, transaction behavior) warrant additional scrutiny.
Digital onboarding with automated ID and sanctions verification ensures proportional yet compliant KYC.

c. Transaction Monitoring and Reporting

Outsourced blockchain analytics and rule-based KYT systems provide automated alerts without requiring a large in-house monitoring team.
Alert review frequency and escalation are risk-based: daily for high-risk, weekly for low/medium.
UTR reporting remains centralized under the MLRO for consistency and efficiency.

d. Training and Awareness

All employees receive AML/CFT onboarding and annual refresher training.
Specialized training is delivered only to roles with direct AML/CFT impact (Operations, Compliance).
External e-learning and CBCS guidance materials are used in place of developing training materials internally.

e. Independent Review

Conducted annually by an independent consultant or internal auditor not involved in daily operations.
Review scope and depth are scaled to the volume and complexity of transactions and number of clients.

14.5 Continuous Improvement and Scalability

Bitkaya continuously evaluates the adequacy of proportionality measures through:

Annual (compliance) review of risk exposure and resource capacity.
Feedback from internal audits, regulatory inspections, and FIU interactions.
Integration of lessons learned into policy revisions.

As Bitkaya grows, proportionality will transition into a fully structured three-lines-of-defense model, expanding dedicated compliance and audit staffing, independent control testing, and enhanced governance reporting.

Implementing Procedures and Controls

Procedures

Controls

Manual Implementation Coverage

Sections 1-3 — Policy, governance and risk-based approach: PROC-AML-001 Maintain AML Risk Assessment and SARA Calibration, PROC-AML-010 Review AML Policy and Proportionality Implementation and PROC-EMP-008 Screen Personnel Before Employment, controlled by CTRL-AML-001 Ensure AML Risk Assessment and SARA Calibration Are Current, CTRL-AML-010 Ensure AML Policy Review and Proportionality Are Maintained and CTRL-EMP-008 Ensure Personnel Screening Is Completed Before Employment.
Section 4 — CDD, KYT, KYV, sanctions and transaction monitoring: PROC-AML-002 Perform Client Acceptance CDD EDD and Risk Classification, PROC-AML-003 Perform Sanctions Screening and Restrictive Measures Escalation, PROC-AML-004 Perform Transaction Monitoring and Alert Review and PROC-AML-006 Apply Travel Rule and Counterparty VASP Due Diligence, controlled by CTRL-AML-002 Ensure CDD EDD and Client Acceptance Are Completed, CTRL-AML-003 Ensure Sanctions Screening and Restrictive Measures Operate, CTRL-AML-004 Ensure Transaction Monitoring Alerts Are Reviewed and CTRL-AML-006 Ensure Travel Rule KYV and Wallet Verification Are Applied.
Section 5 — FIU reporting and restrictions: PROC-AML-005 Perform FIU Reporting and Case Escalation and CTRL-AML-005 Ensure FIU Reporting and Case Escalation Are Completed.
Section 6 — Travel Rule and wallet ownership: PROC-AML-006 Apply Travel Rule and Counterparty VASP Due Diligence and CTRL-AML-006 Ensure Travel Rule KYV and Wallet Verification Are Applied.
Section 7 — Recordkeeping: PROC-AML-007 Maintain AML Records and Data Retention and CTRL-AML-007 Ensure AML Records Are Retained and Retrievable.
Section 8 — Training: PROC-AML-008 Deliver AML Training and Awareness and CTRL-AML-008 Ensure AML Training Is Completed.
Section 9 — Technology and systems: PROC-AML-011 Govern AML Technology and Systems and CTRL-AML-011 Ensure AML Technology and Systems Controls Operate.
Section 10 — Independent review: PROC-AML-009 Perform AML Independent Review and Remediation and CTRL-AML-009 Ensure AML Independent Review Findings Are Tracked.
Section 11 — Policy management: PROC-AML-010 Review AML Policy and Proportionality Implementation and CTRL-AML-010 Ensure AML Policy Review and Proportionality Are Maintained.
Section 12 — Client acceptance SOP: PROC-AML-002 Perform Client Acceptance CDD EDD and Risk Classification and CTRL-AML-002 Ensure CDD EDD and Client Acceptance Are Completed.
Section 13 — Wallet ownership SOP: PROC-AML-006 Apply Travel Rule and Counterparty VASP Due Diligence and CTRL-AML-006 Ensure Travel Rule KYV and Wallet Verification Are Applied.
Section 14 — Proportionality: implemented across PROC-AML-001 Maintain AML Risk Assessment and SARA Calibration, PROC-AML-004 Perform Transaction Monitoring and Alert Review, PROC-AML-008 Deliver AML Training and Awareness, PROC-AML-009 Perform AML Independent Review and Remediation and PROC-AML-010 Review AML Policy and Proportionality Implementation, controlled by CTRL-AML-001 Ensure AML Risk Assessment and SARA Calibration Are Current, CTRL-AML-004 Ensure Transaction Monitoring Alerts Are Reviewed, CTRL-AML-008 Ensure AML Training Is Completed, CTRL-AML-009 Ensure AML Independent Review Findings Are Tracked and CTRL-AML-010 Ensure AML Policy Review and Proportionality Are Maintained.