Skip to content

Compliance controls

Compliance checks run inside the money path, not after it. A transfer cannot complete until every required check has passed, and every result is kept as evidence.

Who uses it: compliance and risk officers in the back office. Name and list screening of customers runs in the back-office system — in Qirin X’s 1 Core System, see Name screening.

  • Every counterparty address on deposits and withdrawals is screened through a pluggable blockchain-analytics provider.
  • Results are classified as hosted (a service provider), self-hosted, protocol (review) or high-risk (reject).
  • The risk thresholds for review and rejection are settings.
  • A provider timeout is retried automatically. Repeated failure goes to an officer to re-screen.
  • Every screening request and result is stored.

Customers prove they control a self-hosted wallet before using it. Two methods are accepted:

  • Message signature. The customer signs a challenge message with the wallet.

  • Micro-transfer test. The customer sends a small, specific amount from the wallet.

  • The own-wallet-only policy is a setting, for incoming and / or outgoing transfers at any amount.

  • Proven wallets go on the customer’s whitelist.

  • A wallet shared by two customers, or a customer wallet that matches a company address, raises an alert.

  • Originator and beneficiary data are held in the IVMS101 data model.
  • The data fields follow the legal value tiers.
  • Messages are append-only, sealed with a SHA-512 manifest and a hash chain.
  • Counterparty name matching uses configurable accept and review scores.
  • Each transfer carries its gate reason: not sent, data incomplete, inbound data missing, name mismatch, awaiting acceptance, acceptance overdue.
  • An outgoing transfer to a hosted wallet is released only after the receiving provider accepts.
  • Messaging-network neutral: Trading Core connects to the Travel Rule network the client contracts with.
  • An officer’s clearance of a gate needs four-eyes approval.
  • Name and list screening (sanctions and domestic lists) runs in the KYC / CDD system.
  • Trading Core requests a verdict for each transfer and acts on the answer: release, hold or reject.
  • The back-office system can restrict each function of an account separately: trading, deposits and withdrawals, fiat and digital asset.
  • Trading restriction modes: block all, or buy-only.
  • Restrictions are enforced in the database on every money path, including desk actions and reversals.
  • Transfers by the same customer in the same direction within a rolling 24 hours are linked when they go to the same address or a similar counterparty name.
  • The linked total decides which value tier of Travel Rule data applies.
  1. The customer requests a withdrawal to a whitelisted address and sees the pre-withdrawal statement.
  2. The amount moves from available to held.
  3. The address is screened. A self-hosted address must already have ownership proof.
  4. The Travel Rule message is built. For a hosted wallet, the transfer waits for the receiving provider to accept.
  5. The back-office system returns its verdict, and the system checks that withdrawals are not restricted on the account.
  6. When every gate is clear, the wallet provider signs and broadcasts the transfer.
  7. On-chain confirmation completes the withdrawal. Completion is one-way. The outflow is matched and the event goes to the back office.
  • Rejects a high-risk address and sends protocol results to review.
  • Refuses a self-hosted address without ownership proof where the own-wallet-only policy applies.
  • Holds an outgoing transfer to a hosted wallet until the receiving provider accepts.
  • Refuses an officer’s gate clearance without four eyes.
  • Never edits a Travel Rule message; messages are append-only and hash-chained.
  • Refuses any action an account restriction forbids, on every screen and interface.
  • Acts on the back-office verdict: release, hold or reject.