Shared Crypto Risk Registry

What RegTech is, and — just as importantly — what it is not.

RegTech is a shared negative-information bureau for the Indonesian crypto industry. Exchanges contribute records about risky identifiers — wallet addresses, national IDs, phone numbers, bank accounts — and query the pool before onboarding or during ongoing monitoring. OJK and the Asosiasi govern the system so that no single participant can weaponise it.

The mental model is a fraud bureau, not a blocklist. A blocklist is a flat list of "banned" values; a bureau records who alleged what, on what evidence, with what confidence, and whether it was contested. That distinction drives every design choice below.

One hashed-match core, delivered in three waves of increasing depth and risk.

Three participant classes for launch. Banks and other institutions are deferred to a later phase.

The single most important design decision. It keeps exchange autonomy while containing defamation and abuse risk.

Any exchange can instantly set a status — including Blacklisted — on an identifier. But a status is always attributed to and scoped by the reporting source. A record never means an anonymous, system-wide verdict; it means "Exchange A asserts this."

When a consumer queries an identifier, they see the full set of attributed claims and decide for themselves. One exchange's unreviewed hunch never becomes an industry-wide sentence.

Status, reason code, confidence and expiry are separate fields — never one flat label. A controlled vocabulary replaces free text.

The atom is an Identifier, not a person — you rarely have full identity, and one actor spans many identifiers. Relations connect them into a graph, so a flagged address carries its deposit / withdrawal / counterparty context.

The registry can answer "is this identifier flagged?" without holding a plaintext honeypot of national IDs.

Every sensitive identifier goes through the same deterministic transform before storage or lookup:

• Normalize & canonicalize — phone → E.164, NIK → digits only, EVM address → checksummed and chain-namespaced (eip155:1:0x…). Equal inputs must yield equal outputs for matching to work.
• System-wide pepper (HMAC key), not per-record salt — matching requires deterministic hashes, so a shared secret pepper replaces per-record salt.
• Pepper lives in an HSM / KMS, never in the database. A DB breach alone cannot brute-force the small NIK space without it — the pepper is the load-bearing secret.
• Wallet addresses stay plaintext (already public on-chain) — preserving readable dashboards and on-chain analytics.

Three intake channels, but one normalization + validation core. Never build three parallel ingest paths.

Validation rejects malformed NIKs, unknown reason codes, missing expiry dates, and self-reports of an exchange's own known infrastructure addresses (see §12).

How value is actually delivered. API-first; the dashboard is a client of the same API.

Attribute-based: role × data-sensitivity × action. Different consumers get different depth.

Scoped = sees the claim and reporting exchange's identity per governance policy; Aggregate = statistical, not per-lookup detail.

Every record moves through a defined lifecycle. Nothing is permanent; everything is contestable.

The failure modes that quietly kill shared-blacklist schemes — designed against from the start.

The foundation. Get this wrong and the software is irrelevant.

Indicative shape for Phase 1 — deliberately boring and auditable. Detail firms up after the data model is signed off.

• API-first — the monitoring dashboard consumes the same public API, so nothing is dashboard-only.
• Separation of secrets — pepper and evidence keys live in the HSM/KMS, isolated from the registry DB.
• Onshore, certified hosting — pending confirmation of OJK residency requirements.

Indicative, pending stakeholder sign-off on the data model and legal basis.

Points to resolve with OJK and the Asosiasi before build. These shape everything downstream.

• Corroboration threshold — how many independent reports (and at what reputation weight) auto-promote a claim to System-Confirmed?
• Peer visibility — do exchanges see which peer filed a claim, or only that "a claim exists"? Affects trust and gaming.
• Dispute SLA & owner — who fields data-subject disputes, and within how many days?
• Retention defaults — confirm per-status review periods against OJK / PDP guidance.
• Data residency — confirm the required hosting jurisdiction and certification.
• PPATK interface — is there a formal hand-off pathway for confirmed AML cases, and in which phase?
• Non-exchange consumers — when (if ever) do banks / fintechs get query-only access, and on what basis?