High-Level Overview of Principal OTC Service Delivery

Purpose

Define the end-to-end operating process for Bitkaya’s principal OTC virtual-asset trades, from client readiness and quote acceptance through pre-trade compliance, settlement, treasury inventory management, reconciliation, accounting, post-trade monitoring and record retention.

Policy Framework

Enterprise Compliance

• POL-ECM-001 Enterprise Compliance Manual

Governance, Risk and Outsourcing

• POL-ESG-001 Governance Ethics and ESG Manual
• POL-RMF-001 Risk Management Framework Manual
• POL-OUT-001 Outsourcing Risk Management Manual

Financial Crime and Integrity

• POL-AML-001 AML CTF CPF Compliance Manual
• POL-ABC-001 Anti-Bribery and Corruption Manual
• POL-KYC-001 KYC and CDD Manual

Client Protection and Operations

• POL-SAFU-001 Client Asset Protection and Safeguarding Manual
• POL-COMM-001 Client Communication and Promotion Compliance Manual
• POL-COMP-001 Client Complaints Handling Manual
• POL-MCT-001 Market Conduct and Trading Compliance Manual
• POL-PRIV-001 Data Protection and Privacy Manual

Resilience, Systems and Assurance

• POL-BCM-001 Business Continuity Manual
• POL-IT-001 IT and Cybersecurity Manual
• POL-COTS-001 Commercial Off-The Shelf Software Acceptance and Testing Manual
• POL-FIN-001 Finance and Tax Compliance Manual
• POL-EMP-001 Employee Handbook
• POL-ICA-001 Internal Controls and Audit Manual
• POL-REG-001 Regulatory Reporting and Communication Manual
• POL-TRAIN-001 Training and Awareness Manual
• POL-ODOO-001 Odoo SaaS Backup Policy

Trigger

This process starts when an approved client requests an OTC quote or when onboarding, settlement, treasury, reconciliation, monitoring or exception activity is required for a proposed or completed OTC trade.

High-Level Flow

Onboard and approve client -> capture trade intent -> determine and communicate quote -> record client acceptance -> perform pre-trade compliance checks -> reject, escalate or book trade -> verify incoming settlement asset -> release countervalue -> perform post-trade KYT -> manage proprietary inventory and approved hedging -> reconcile bank, wallet, order and ledger records -> monitor, report and retain evidence.

Inputs

• Approved client, beneficial-owner, risk, sanctions, wallet and bank-account records.
• Client trade request, asset, network, direction, amount and intended settlement instructions.
• Quote, acceptance, trading-limit and inventory information.
• Pre-trade and post-trade KYC, KYT, sanctions and transaction-monitoring results.
• Fiat receipt, blockchain transaction, confirmation and settlement evidence.
• Treasury inventory, venue, counterparty, hedging and liquidity information.
• Odoo order, inventory transfer, accounting and reconciliation records.

Outputs

• Accepted, rejected, expired or escalated quote and trade record.
• Documented pre-trade compliance result and authorization.
• Verified fiat or virtual-asset receipt and controlled countervalue release.
• Post-trade KYT result, disposition and reporting decision where applicable.
• Updated proprietary inventory, treasury and approved hedge record.
• Reconciled order, bank, wallet, inventory and accounting records.
• Complete audit trail, exception, escalation, reporting and retention evidence.

Roles

• Sales or the dealing function captures trade intent, communicates approved quotes and records acceptance without bypassing controls.
• Operations verifies client readiness, settlement instructions, receipts, blockchain confirmations, KYT results, release conditions and operational records.
• Compliance owns AML, sanctions, KYC/KYT escalation, restrictive-measure and FIU-reporting decisions.
• Treasury manages Bitkaya proprietary inventory, liquidity, exposure and approved external-venue activity within limits.
• Finance records transactions, performs bank and ledger reconciliation and supports financial and tax reporting.
• Technology maintains approved systems, access, automation, logs, resilience and change control.
• Management approves residual business-risk decisions within delegated authority but cannot override mandatory legal or compliance requirements.
• Independent reviewers test control design, segregation, evidence and operating effectiveness.

Operating Components

1. Complete KYC/KYB, risk classification, sanctions screening and wallet and bank-account validation before trading access.
2. Capture the client’s asset, network, direction, amount and settlement intent and provide an authorized quote.
3. Record client acceptance and perform required pre-trade compliance and limit checks before booking or release.
4. For a client purchase, confirm irrevocable fiat receipt before releasing virtual assets to an approved client wallet.
5. For a client sale, confirm the virtual-asset receipt, required network confirmations and relevant KYT result before releasing fiat to the approved client bank account.
6. Record post-trade KYT, investigate non-clear outcomes and assess restrictions, FIU reporting and retrospective action.
7. Review resulting proprietary fiat and virtual-asset inventory and execute only approved, risk-controlled rebalancing or hedge transactions with approved venues or counterparties.
8. Reconcile orders, settlement evidence, wallets, bank accounts, inventory and accounting records and resolve every unexplained difference.
9. Retain evidence, perform ongoing monitoring and complete regulatory, management and financial reporting where applicable.

Process Rules and Boundaries

• This process is an overview. The linked procedures control detailed onboarding, screening, monitoring, release, reconciliation, reporting, security and exception handling.
• A client or trade may not progress while mandatory KYC, sanctions, KYT, limit, source, settlement or approval requirements remain unresolved.
• Quote acceptance is not compliance approval and does not create authority to release or settle.
• Client settlement assets must not be treated as Bitkaya proprietary inventory before the legally and operationally defined transfer point is complete.
• The memo’s principal-counterparty and proprietary-inventory description is an operating assumption subject to the accounting, tax, legal and safeguarding confirmation tracked under ISS-FIN-001 Confirm Finance and Tax Sources Thresholds Systems and Operating Evidence and ISS-SAFU-001 Confirm Safeguarding Architecture Legal Protections and Operating Evidence.
• The statement that this flow does not provide custody applies only to the described OTC settlement flow and must not be used as an enterprise-wide conclusion about other services.
• Where one person performs multiple tasks under proportionality, independent review, access control, dual approval, reconciliation or another documented compensating control is required.

Relationships

• Architecture decision: ADR-003 Flatten Compliance Process Architecture
• Approved process memo: PUB-OTC-001 Bitkaya Principal OTC Service Flows Memo
• KYT SOP: PUB-KYT-001 Odoo Pre-Trade and Post-Trade KYT Controls SOP
• Review issue: ISS-OTC-001 Review and Complete Principal OTC Service Flow Controls

Assurance

• Design status: implemented from the approved Service Flows Memo version 1.0
• Operating assurance: pending system-derived assessment
• Process architecture review status: current as of 2026-07-26
• Underlying Service Flows Memo review status: overdue since 2026-07-01
• Evidence status: expected evidence is defined by the linked controls and publications
• Overall status: implemented process overview; exception design, system mapping, legal/accounting conclusions and operating effectiveness remain open under ISS-OTC-001 and linked issues

History

• 2026-07-26: Aligned assurance wording with the system-derived Hermes/Odoo result model.
• 2026-07-26: Registered the approved principal OTC service-flow process and mapped it to existing compliance, settlement, treasury, finance and technology controls.
• 2026-07-26: Retitled and adopted as the high-level overview in the flattened five-process architecture; added direct links to the complete policy framework.