Case 1 — Cross-Issuer B2B Settlement

Scenario

Alice Corp (HK company, KYC level 4 institutional, VASP identifier: HSBC) pays Bob Ltd (HK company, level 4, VASP identifier: Anchorpoint) for an outstanding invoice. This case walks the compliance flow across three transfer amounts to show the full spectrum of Hkchain's compliance behavior:

• Variant A: HKD 500 — small, auto-passes with minimal Travel Rule
• Variant B: HKD 50,000 — medium, triggers threshold flag, reviewer approves
• Variant C: HKD 5,000,000 — large, triggers threshold + velocity flags, reviewer escalates to officer

All three use the same underlying machinery; only amount and resulting flag path differ.

Actors

For this case, Alice holds hkd.hsbc (previously minted by HSBC against HSBC's reserves). Bob accepts hkd.hsbc (he may later redeem with HSBC or keep). No cross-denom conversion is required in this case — that would be a separate case (future docs).

Preconditions

• Alice is at L4 with an off-chain IVMS101 payload held by HSBC (PII hash on chain)
• Bob is at L4 with off-chain IVMS101 held by Anchorpoint
• Neither party is on the sanctions set
• HSBC has an ATTESTED reserve covering current circulation
• Alice holds HKD 10,000,000 in hkd.hsbc (more than enough for any variant)

Variant A — HKD 500 (auto-pass, minimal Travel Rule)

Step 1 — Alice's treasury system constructs the transaction

MsgSend {
  from: hkchain1alice..., to: hkchain1bob..., denom: hkd.hsbc, amount: 50000  // minor units
}
tx extension: TravelRulePayload {
  originator: { vasp: HSBC, entity_ref: ALICE-001 },
  beneficiary: { vasp: Anchorpoint, entity_ref: BOB-A-017 }
}

Note: the extension only needs minimal IVMS101 fields because the amount is below the HKD 8,000 enhanced-fields threshold.

Step 2 — AnteHandler decorators run

Step 3 — Transfer executes

x/bank moves 500 HKD from Alice to Bob. x/compliance.AppendAudit(TransferEvent{…, travel_rule_hash: 0x…, flags: []}).

Step 4 — What each role sees

• Alice: tx succeeded; balance updated.
• Bob: balance updated.
• HSBC Compliance Reviewer: nothing in queue (no flag raised).
• HSBC Compliance Officer: nothing in queue.
• Anchorpoint Compliance: tx visible in their incoming audit log, no flag; routine CPF review per their internal policy.
• HKMA Supervisor: tx appears in their live event feed as a benign transfer, contributing to the daily circulation statement.

Elapsed time: one block. No human intervention required.

Variant B — HKD 50,000 (threshold flag, reviewer approves)

Step 1 — Transaction constructed with full IVMS101

Because 50,000 ≥ HKD 8,000, the TravelRulePayload must include the enhanced field set:

TravelRulePayload {
  originator: {
    name: "Alice Corp",
    address_hash: 0xabc…,  // physical address, hashed
    date_of_incorporation_hash: 0xdef…,
    vasp: HSBC, entity_ref: ALICE-001
  },
  beneficiary: {
    name: "Bob Ltd",
    address_hash: 0x123…,
    vasp: Anchorpoint, entity_ref: BOB-A-017
  },
  purpose: "invoice INV-2026-0418"
}

The full payload lives off chain with HSBC (originator's VASP); only the hash is on chain.

Step 2 — AnteHandler

FlagEmitted event: {flag_id: F-2026-04-19-001, tx_hash, reasons: [threshold(50000)], state: EMITTED}.

Step 3 — Transfer still executes

Threshold is advisory in MVP: the transfer completes. Only a flag is raised for later review.

Step 4 — Reviewer picks up the flag

In the HSBC Compliance Console (/compliance/review-queue?issuer=HSBC), the reviewer sees a new flag for F-2026-04-19-001. They click in:

• Transfer details: amount, denom, parties, block height, Travel Rule payload hash
• Historical context: Alice's recent transaction pattern (auto-rendered from audit log)
• Reviewer's off-chain case system opens (via deep link) for invoice INV-2026-0418 verification

The reviewer pulls HSBC's internal KYC file and the invoice PDF, confirms the payment is consistent with Alice's normal business pattern, and clicks Approve.

MsgReviewFlag {
  flag_id: F-2026-04-19-001,
  decision: APPROVED,
  evidence_hash: 0xe1e1e1…   // hash of reviewer's memo in HSBC's case management system
}

Signed by the reviewer sub-key (hkchain1hsbcrev…). The RoleGateDecorator verifies the signer is bound as a reviewer under HSBC; message type is in the allowlist. Accepted.

x/compliance transitions flag state to RESOLVED_APPROVED. Emits FlagResolved event.

Step 5 — What each role sees now

• HSBC Compliance Reviewer: flag moved from "open" queue to "recently resolved"
• HSBC Compliance Officer: no action needed (not escalated)
• Anchorpoint Compliance: sees incoming transfer in their audit log with Bob as recipient; optionally runs their own review (independent of HSBC)
• HKMA Supervisor: flag appears in event feed with its full lifecycle — FlagEmitted → FlagResolved{APPROVED}, linked to the transfer and the reviewer's evidence hash
• Alice and Bob: neither sees any interruption; tx executed normally

Elapsed time: one block for tx; typically minutes to hours for human review (SLA per issuer policy).

Variant C — HKD 5,000,000 (flag + escalation to officer)

Step 1 — Transaction constructed (enhanced Travel Rule as before)

Step 2 — AnteHandler

FlagEmitted: {flag_id: F-2026-04-19-002, reasons: [threshold(5000000), velocity(4tx/1h)], state: EMITTED}.

Step 3 — Transfer still executes

Both decorators are advisory. The flag is emitted with two reasons; transfer completes.

Step 4 — Reviewer escalates

HSBC's reviewer opens the flag. The combination of amount and velocity triggers their internal policy to escalate. They sign:

MsgReviewFlag {
  flag_id: F-2026-04-19-002,
  decision: ESCALATED,
  evidence_hash: 0xf0f0f0…   // reviewer's initial investigation notes
}

Flag state transitions: EMITTED → PENDING_OFFICER. Reviewer's queue no longer shows this flag; the Officer's queue does.

Step 5 — Officer reviews

HSBC's compliance officer (hkchain1hsbcofc…, role=officer) opens the escalated flag. They pull additional context:

• Alice's full KYC profile
• Pattern of recent large transfers
• Any adverse-media signals (off-chain screening)
• Communication with the client's treasury desk to verify the transfer

In this scenario the officer verifies the transfer is a legitimate scheduled acquisition payment, documented in HSBC's records. They sign:

MsgCloseFlag {
  flag_id: F-2026-04-19-002,
  officer_sig,
  decision: APPROVED,
  evidence_hash: 0x9a9a9a…   // officer's close memo
}

The RoleGateDecorator verifies the officer sub-role. Accepted. Flag state → RESOLVED_APPROVED. Emits FlagResolved.

Alternative sub-path — officer blocks

Had the officer found the transfer inconsistent with Alice's normal activity or indicative of suspicious behavior, they could have signed:

MsgCloseFlag {
  flag_id: F-2026-04-19-002,
  officer_sig,
  decision: BLOCKED,
  evidence_hash: 0x8b8b8b…
}

This records the flag as RESOLVED_BLOCKED and may be followed by MsgBlacklist(alice_address) if internal determination supports it. The transfer already executed (advisory flags don't block inclusion), so actual remediation — clawback, account freeze, SAR filing — happens as separate on-chain + off-chain actions.

For future (outside MVP scope), Hkchain could offer optional "hold until reviewed" semantics for certain high-risk rules, but this is an anti-pattern for general use because it creates UX unpredictability.

Step 6 — What each role sees

• HSBC Reviewer: flag moved from their queue after escalation
• HSBC Officer: flag in their queue, then moved to "recently resolved"
• HKMA Supervisor: full lifecycle visible — FlagEmitted (with two reasons) → FlagEscalated → FlagResolved{APPROVED|BLOCKED}, all linked and queryable
• Alice, Bob: no visible interruption (tx executed); if Alice were later blocked by MsgBlacklist, subsequent transfers would fail at AnteHandler

What this case demonstrates

• Chain-level Travel Rule enforcement (zero-threshold for every tx; enhanced at ≥ HKD 8,000)
• Auto-decided cases where no flag is raised — the common case, no human friction
• Flag-and-review for larger transfers, with full audit trail of the reviewer's decision and evidence hash
• Escalation path for the most consequential decisions, requiring a second signatory in a higher role
• Role separation — reviewer and officer are distinct sub-keys with distinct allowlists, enforced by the AnteHandler
• Supervisor observability — HKMA sees the full lifecycle of each flag without needing to ask the issuer for data
• Interoperability — the same compliance model serves both issuers involved; Anchorpoint (recipient side) has symmetric observability over their own customer

Forward-looking notes (not in MVP)

• The reviewer role is a natural candidate for AI-assisted triage: the AI recommends an action (approve / escalate) and drafts the evidence memo; the human reviewer confirms. See future/ai-agent-compliance-review.md for the longer-term vision. MVP keeps humans in both loops.
• True cross-denom B2B settlement (Alice holds hkd.hsbc, Bob accepts only hkd.ap) requires either a neutral intermediary or an on-chain redemption-and-reissuance flow. Out of MVP scope; the single-denom path is sufficient to demonstrate the compliance story.