Bitkaya Compliance Management System (BCMS)
Internal Memorandum — High-Level Overview
Date: 2026-07-28 From: Compliance Classification: Internal Audience: Board of Directors, Senior Management, Supervisors
Purpose
This memorandum provides a high-level overview of Bitkaya’s Compliance Management System (“BCMS”) — how it is structured, how it operates, and how it is implemented across the organization. The intent is to give supervisors and management a clear, non-technical understanding of the system without going into specific tooling or implementation details.
What the BCMS Is
The BCMS is Bitkaya’s structured framework for managing compliance across all regulatory obligations applicable to its operations as a Virtual Asset Service Provider (VASP). It serves as the single source of truth for policies, procedures, controls, and the relationships between them.
Rather than maintaining compliance documentation in isolated documents or folders, the BCMS organizes everything into a connected system where each object has a defined type, owner, status, and set of relationships to other objects. This means that when a regulation changes, the system can identify exactly which policies, procedures, and controls are affected — and who needs to act.
How the BCMS Is Structured
The system is built around a layered architecture, moving from regulatory sources down to operational controls:
1. Regulatory Sources — External laws, guidelines, and standards that Bitkaya must comply with (e.g., CBCS regulations, FATF standards, Curaçao legislation).
2. Regulatory Requirements — Specific obligations extracted from the sources, broken down into individually tracked requirements with clear ownership and testable criteria.
3. Processes — High-level business processes that describe how Bitkaya operates (e.g., client onboarding, OTC trading, outsourcing management). Processes provide the operational context for compliance.
4. Policies — Approved compliance manuals and frameworks that translate regulatory requirements into internal commitments. Each policy is an authoritative document covering a domain (e.g., AML/CFT/CPF, risk management, data protection). Policies are version-controlled and carry approval metadata including who approved them, when, and when they are next due for review.
5. Procedures — Step-by-step operational instructions that implement the policies. Each procedure describes what needs to be done, by whom, in what order, and what evidence must be retained. Procedures are owned by operational teams and reviewed periodically.
6. Controls — Verification activities that confirm the procedures were followed correctly and the policy objectives are being met. Each control has a defined testing method, evidence expectations, and testing frequency. Controls are the mechanism through which compliance assurance is delivered.
7. Systems — The systems and tools that support the execution of procedures and controls (e.g., the CRM, the compliance evidence repository, blockchain analytics).
8. Issues — Identified gaps, conflicts, or open questions that require resolution. Issues are tracked with impact assessments, resolution plans, and validation criteria.
9. Change Requests — Formal proposals to modify any of the above. Every content change — whether to fix an issue, respond to a regulatory update, or improve a process — goes through an approved change request on a dedicated branch before being merged into the authoritative version.
How It Works in Practice
Documenting Compliance
Each compliance domain (AML, outsourcing, risk management, privacy, etc.) has its own policy manual, a set of implementing procedures, and a set of controls. These are linked together so that:
- A policy references its implementing procedures and controls
- A procedure references the policy it implements and the control that verifies it
- A control references the procedure it tests and the policy it supports
- All objects trace back to the regulatory requirements and sources they address
This cross-referencing means that from any starting point — a regulation, a policy, a procedure, or a control — you can trace the full chain of compliance.
Approving Changes
Changes to the BCMS follow a controlled workflow:
- A change request is created, describing what needs to change and why
- The change is reviewed and approved by an authorized person (typically the Managing Director or Board, depending on the criticality)
- The approved change is implemented on a separate branch and merged only after approval
- When ready, the affected policy artifacts are regenerated as new approved versions
- The change request and any related issues are closed with full traceability
No changes are made directly to the authoritative version without going through this process.
Generating Approved Artifacts
The BCMS produces formal, branded PDF manuals from the structured content stored in the system. These artifacts are:
- Generated on demand when changes are approved and ready for publication
- Versioned with clear metadata (document ID, version, approval date, approver)
- Reproducible — the same content always produces the same artifact
- Comparable — new versions can be diffed against previous versions to see exactly what changed
This means the approved PDF manuals are always a faithful representation of what is in the system, and any discrepancy can be traced to a specific approved change.
How Compliance Assurance Works
The BCMS supports a three-lines model for compliance assurance:
-
First line (Operations) owns and executes the procedures — they perform the client onboarding, the sanctions screening, the reconciliations, and the monitoring. They are responsible for completing each step correctly and retaining the required evidence.
-
Second line (Compliance and Risk) owns the controls — they design the testing methodology, define what evidence is expected, and perform periodic testing to confirm that the first line is operating effectively. They also maintain the BCMS itself, ensuring that policies and procedures remain current.
-
Third line (Independent Review) provides assurance over the control framework — internal audit or an external reviewer assesses whether the controls are designed correctly and operating effectively, and reports findings to the Board.
Each layer has visibility into the one below it through the BCMS: controls reference the procedures they test, and assurance findings reference the controls they reviewed.
Review and Maintenance
The BCMS is not a static document set — it is designed for continuous maintenance:
- Policies are reviewed at least annually and whenever there is a material change in regulation, business model, or risk profile
- Procedures are reviewed whenever their parent policy changes or when operational changes require it
- Controls are tested at a frequency proportionate to the risk they mitigate (annual for high-risk, every two years for medium, every three years for low)
- Issues are tracked to closure with defined resolution plans and validation criteria
- Change requests ensure that every modification is deliberate, reviewed, and traceable
What This Means for Supervisors
As a supervisor or manager, the BCMS gives you:
- Clarity — you can see exactly what your team is responsible for, what the steps are, and what evidence is expected
- Traceability — you can trace any requirement from regulation to policy to procedure to control
- Accountability — every object has a named owner, approver, and review date
- Change control — you know that nothing changes without an approved change request, and you can see what changed and why
- Assurance — controls are tested and findings are tracked, so you have evidence that the framework is operating, not just documented
The system is designed to be proportionate to Bitkaya’s current scale while being scalable as the organization grows. Functions may be consolidated where appropriate, but the governance, risk assessment, and control testing disciplines are maintained regardless of size.
This memorandum provides a high-level overview only. For specific policies, procedures, or controls, refer to the relevant BCMS objects directly. For questions about the system, contact Compliance.
Bitkaya B.V. · Julianaplein 36, Willemstad, Curaçao · Dutch Caribbean · www.bitkaya.io