Hkchain
Roadmap — not part of the shipped system

Forward-Looking — AI-Assisted Compliance Review

Status: exploratory idea. Not in MVP scope. Listed here so that the architectural path remains open and stakeholders can see where Hkchain is heading.

Note (2026-04-19): This document originally covered two forward-looking tracks:

  1. User-to-agent delegation (a user binds an AI agent for autonomous HKD spending within policy limits)
  2. AI agents in the compliance reviewer role

Track 1 has since shipped as the agent sub-role with a chain-enforced policy envelope — see Agentic payment via HTTP 402 and Roles and permissions. The rest of this document concerns Track 2 only — AI agents acting as compliance staff, not as customers.

The problem

Compliance reviewer workload scales with transaction volume. A successful stablecoin rail accumulates flags faster than compliance teams can meaningfully review them. The industry response today is either:

  • Tight thresholds (fewer flags) — but this means missed signals and weaker AML coverage
  • Larger compliance teams — expensive; throughput still bounded by human review speed
  • Pure automation (rule-based, no human) — fragile; misses nuance; hard to explain to regulators

None of these gracefully absorb 10x or 100x volume growth while maintaining regulatory quality.

The Hkchain opportunity

Hkchain's reviewer workflow is already modeled as a role-bound message set (MsgReviewFlag, MsgEscalateFlag, MsgCloseFlag) with evidence hashes pointing to off-chain decision artifacts. This is almost exactly the interface an AI agent needs: a well-typed action space with evidence commitments.

The progression:

Phase 1 — AI as triage assistant (most conservative)

An LLM service subscribes to FlagEmitted events. For each, it:

  • Pulls transaction context (amount, parties, Travel Rule metadata)
  • Pulls historical context (audit log for involved addresses)
  • Produces a recommendation (approve / escalate / block) with a confidence score and a draft memo
  • Surfaces recommendation and memo in the human reviewer's queue UI

Human reviewer still clicks. AI is decision support, not decision maker. This alone likely raises reviewer throughput 3–5x.

Phase 2 — AI as auto-approver for high-confidence benign cases

For flags that meet strict high-confidence criteria (e.g., threshold-only flags on established L4 institutional customers with clean history), the AI signs MsgReviewFlag{decision: APPROVED} itself, under a constrained AI reviewer sub-role bound by:

  • Per-day action cap
  • Per-flag confidence threshold
  • Full decision traceability (the AI's reasoning is written to IPFS; hash committed on chain)
  • Sampling: a random X% of auto-approvals are routed back to human review as quality check

Humans stay in the loop for all low-confidence cases, all block decisions, and all escalations.

Phase 3 — AI as reviewer with officer supervision

AI reviewer sub-role handles the full reviewer action space (approve, escalate, block) under officer-defined policy. Officer retains sole authority to close escalations. An AI's block decision still gets recorded and follows the same post-block remediation path.

Phase 4 — distributed AI reviewer pool

Multiple AI reviewer keys, redundancy on action-critical flags (require 2-of-N AI agreement), provenance-diverse training, independent audit of AI behavior.

Why this works on Hkchain specifically

  • Role-bound messages — AI cannot mint, burn, or pause no matter how off-policy it goes. The chain enforces the boundary.
  • Evidence hashes — every AI decision has a traceable artifact. Not "the AI said so"; "here's the exact reasoning the AI committed to."
  • Officer sovereignty — the human officer retains authority over escalated cases and AI policy parameters.
  • Observability — HKMA sees the same audit log whether the reviewer is human or AI. The supervisory surface does not need to change.

Why this is NOT in MVP

  • 2026-05-11 meeting is a rail demonstration; introducing AI-on-AI narrative complicates the regulator conversation
  • Phase 1 requires significant engineering (LLM service, event subscription, UX integration) that would displace core work
  • The risk surface of AI-in-the-loop needs careful, regulator-aware framing that MVP timeline does not permit
  • Phase 2+ presume an operational MVP with enough transaction volume to benefit; we don't have that yet

What we keep in mind during MVP

The MVP design should not close doors for this future. Specifically:

  • The MsgReviewFlag / MsgCloseFlag message schema includes evidence_hash as a first-class field — it's neutral to whether a human or an AI produced the evidence.
  • The sub-role binding model (MsgBindSubRole) is general; a future role: ai_reviewer needs only a new enum value plus an officer-defined policy envelope.
  • The AnteHandler RoleGateDecorator makes AI role boundaries enforceable, not advisory.

In other words: Phase 1 becomes possible with no chain changes, only by adding an off-chain service that subscribes to events and calls existing messages. That's by design.

Related but distinct

  • Agent commerce via x402 (see docs/cases/case-02-agentic-payment-402.md) — agents as customers (they pay for things). This doc is about agents as compliance staff (they process flags). The two are related only in that both benefit from Hkchain's identity + audit + role primitives.