BCMS

Manage Prohibited Restricted and Re-Entry Relationships

3 min read

Purpose

Prevent prohibited relationships and ensure restricted or re-entry cases receive documented escalation and approval.

Preconditions

  • Client, counterparty and screening information is available.
  • Prior exits, rejections and restrictions can be retrieved.

Steps

  1. Check whether the party falls into a prohibited category: 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; or any relationship that Bitkaya cannot lawfully maintain under applicable Curaçao, CBCS, sanctions, or AML/CFT requirements.
  2. If prohibited, stop onboarding or continuing the relationship and preserve the decision evidence. Commercial importance is not a reason to bypass this SOP. No approval may override a genuinely prohibited relationship.
  3. Identify restricted cases: higher-risk VASPs or counterparties in weaker-control jurisdictions; PEP-linked or politically exposed structures (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; and re-entry requests from previously offboarded or rejected clients.
  4. Stop normal processing, document the reason for concern, preserve any supporting records or screening results, and escalate to Compliance. Staff must not override the issue informally.
  5. For re-entry after prior exit: retrieve the prior exit reason; have Compliance review the file; assess any new information; document the reason the risk is considered changed; and obtain Senior Management approval before onboarding may proceed. If the prior reason remains unresolved or the risk is still unacceptable, Bitkaya must refuse the relationship.
  6. Obtain Compliance approval for 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.
  7. Reject the relationship when the prohibition or unacceptable risk remains.
  8. Apply the same checks when new information arises during an existing relationship, 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. The relationship must be reviewed promptly and may need to be paused, restricted, exited, or reported.

Exceptions and Escalation

No person may override a prohibited category. Informal or commercial approval is invalid. Possible sanctions or suspicious-activity cases must follow the dedicated escalation procedures.

Records Created

  • prohibition or restriction trigger;
  • screening and identity evidence;
  • Compliance review;
  • approval, restriction, rejection or exit decision;
  • re-entry rationale where applicable.

Relationships

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

History

  • 2026-07-26: Created from section 14 of the approved KYC & CDD Manual.

Graph View

Backlinks