Purpose

Prevent prohibited relationships and unauthorized progression of restricted or re-entry cases.

Objective

Every prohibition, restriction, override attempt and re-entry request is stopped, escalated and resolved under documented authority.

Normative

Bitkaya shall not onboard or maintain a prohibited relationship. Restricted and re-entry cases shall not proceed without the required Compliance and management approvals. Commercial importance is not a reason to bypass this SOP. No approval may override a genuinely prohibited relationship.

Prohibited categories: 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 acting for or providing services to shell banks in a prohibited manner; sanctioned persons or entities; blocked or frozen parties; clients using Bitkaya for clearly unlawful purposes; clients previously exited for financial-crime reasons unless re-entry is formally approved; any relationship Bitkaya cannot lawfully maintain.

Restricted categories: higher-risk VASPs or counterparties in weaker-control jurisdictions; PEP-linked structures; serious adverse media or integrity concerns; unusually opaque ownership structures; higher-risk sectors, intermediaries, or transactional behavior; unclear rationale, source of funds, wallet provenance, or expected activity; re-entry requests.

Control Activity

Onboarding and review staff apply the approved prohibited and restricted criteria. The workflow is stopped when a trigger is identified. Staff must: stop the process; document the reason for concern; preserve supporting records or screening results; and escalate to Compliance. Staff must not override the issue informally. Compliance records the decision, with Senior Management approval where required. Restricted cases require at least business owner input and Compliance approval. Senior Management approval is required for re-entry after prior exit, high-risk or commercially sensitive cases, serious integrity concerns, or cases that may materially affect Bitkaya’s financial-crime risk profile. For re-entry: 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.

Evidence

  • Expected evidence: screening and trigger evidence.
  • Expected evidence: stop or restriction record.
  • Expected evidence: Compliance assessment.
  • Expected evidence: approval, rejection or exit decision.
  • Expected evidence: prior-exit and re-entry rationale (prior exit reason, new information assessment, documented reason risk is considered changed, Senior Management approval).
  • Expected evidence: minimum file evidence including screening results, identity/ownership information, summary of restriction/prohibition trigger, Compliance review note, approval or rejection outcome, and re-entry rationale if applicable.
  • Evidence location: compliance evidence repository and applicable operating system.
  • Retention: at least five years or longer where required.
  • Testing method: Sample rejected, restricted, exited and re-entry cases and verify the correct authority and rationale.
  • Testing frequency: annual.

Assurance

Runtime effectiveness results are maintained in Odoo and assessed through the Hermes workflow tracked in ISS-HERMES-001. This note defines design, ownership, evidence expectations and testing method; it does not contain a manually maintained operation, evidence or overall effectiveness rating.

  • Design status: implemented from approved KYC & CDD Manual version 1.1

Assurance Assertions

  • No prohibited case was approved by exception.
  • Restricted cases contain Compliance approval.
  • Re-entry cases contain prior-exit review and Senior Management approval.

Relationships

History

  • 2026-07-26: Created from the approved KYC & CDD Manual version 1.1.