BCMS

Ensure Transaction Monitoring Alerts Are Reviewed

4 min read

Objective

Ensure transaction monitoring alerts are generated, reviewed, escalated and disposed with documented rationale.

Control Activity

Compliance or trained operations personnel review fiat and virtual-asset alerts under approved risk-calibrated rules. High-risk populations are reviewed at least daily and low- or medium-risk populations at least weekly, subject to earlier pre-transaction resolution. Targeted tracing normally covers up to three hops and high-risk or escalated cases often up to six, with the actual depth, path, configuration version, score-band interpretation, investigation, disposition and reporting or restriction rationale substantiated in the case.

Monitoring Scope

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

Monitoring Scenarios

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

Fiat Red Flags

  • 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

The 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).

Blockchain Tracing Depth

Bitkaya applies a risk-based approach to blockchain tracing depth. 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.

Threshold Calibration

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. Higher-risk activity is subject to practical, risk-based controls such as transaction limits, additional review, and escalation to Compliance where appropriate.

Evidence

  • Expected evidence: alert queue.
  • Expected evidence: investigation notes.
  • Expected evidence: disposition record.
  • Expected evidence: escalation record.
  • Expected evidence: calibration evidence.
  • Expected evidence: transaction graph, hop-depth rationale and intermediary path.
  • Expected evidence: rule/configuration version and alert-cadence evidence.
  • Evidence location: compliance evidence repository and applicable operating system.
  • Retention: according to Bitkaya AML/CTF/CPF record-retention requirements.
  • Testing method: Sample fiat and crypto alerts across risk levels, directions, thresholds and dispositions; verify queue cadence, transaction and wallet evidence, three-hop or enhanced tracing rationale, exact 25% and 75% boundary treatment, below/boundary/above-threshold handling, trained review, escalation, failed-result handling and closure support.
  • Testing frequency: annual, and after material AML/CTF/CPF changes 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 AML/CTF/CPF Compliance Manual version 2.2

History

  • 2026-07-26: Added alert cadence, hop-depth substantiation, configuration-version and broader fiat/on-chain test expectations after a full manual rescreen.
  • 2026-07-26: Created from the approved AML/CTF/CPF Compliance Manual version 2.2.

Graph View

Backlinks