How should crypto firms build a compliance framework for Indonesia’s new oversight regime?

Crypto firms should treat the new OJK regime as a prompt to tighten governance across the customer lifecycle, not just update policy text. A workable framework starts with risk-based onboarding, continues with transaction monitoring, sanctions and Travel Rule controls, and includes clear escalation paths for suspicious activity. Firms also need documented ownership, audit-ready evidence, and periodic review as rules and supervisory expectations mature.

Building a compliance framework that matches Indonesia’s oversight shift

Indonesia’s new oversight regime changes the compliance problem from a static policy exercise into a governed operating model. Crypto firms need controls that can prove who is onboarded, what activity is monitored, when alerts are escalated, and how decisions are evidenced for review. For this question, the compliance framework is not just a legal wrapper; it is the set of processes, roles, records, and control checks that make customer activity auditable under supervisory scrutiny.

The practical starting point is lifecycle coverage. Risk-based onboarding, sanctions screening, transaction monitoring, suspicious activity escalation, and review cadence need to work as one chain rather than as disconnected tasks. That matters because supervision usually tests whether the firm can explain a decision end to end, not whether a policy exists on paper. A framework should also define ownership, exception handling, and retention so compliance teams can show consistent treatment across customers and product lines. The FATF Recommendations – AML and KYC Framework remain the clearest external reference point for customer due diligence, monitoring, and recordkeeping expectations. In practice, many crypto firms discover gaps only when investigators ask for the decision trail behind a blocked wallet, a missed alert, or a late escalation.

How the control set should work across onboarding, monitoring, and escalation

A workable compliance framework for Indonesian oversight should be built as a sequence of control layers, not as a single compliance checklist. The first layer is customer due diligence: firms need risk scoring that reflects customer type, geography, source of funds where relevant, and product exposure. The second layer is ongoing monitoring: transactions must be screened for patterns that merit review, not just for obvious sanctions hits. The third layer is escalation and disposition: every alert should have a documented path from detection to analyst review to action, with clear thresholds for freezing, offboarding, or reporting.

That structure only functions if the firm can show control ownership and evidence. Compliance, operations, legal, and engineering each need defined responsibilities because gaps usually occur at handoffs. For example, a transaction monitoring rule that generates alerts is not effective if the case management process cannot preserve analyst notes, timestamps, and rationale. Similarly, sanctions controls are weak if list updates, matching logic, and false-positive review are not governed as a repeatable process.

Define onboarding rules that separate lower-risk, standard, and enhanced due diligence cases.
Link monitoring thresholds to customer and product risk rather than using one threshold for all activity.
Document escalation criteria for suspicious activity, sanctions hits, and unresolved anomalies.
Retain evidence that shows who reviewed the case, what they saw, and what action followed.

For firms operating across multiple exchanges, wallets, or custodial models, the framework should also account for data consistency. If customer identity, transaction history, and case outcomes live in separate systems, the compliance model becomes hard to defend because supervisory testing often focuses on completeness and traceability. The NIST Cybersecurity Framework 2.0 is useful here as a governance reference for identifying, protecting, detecting, and responding in a coordinated way. Where the regime breaks down in practice is usually at the point where alert quality, evidence retention, and business exception handling are allowed to drift out of sync.

Where crypto compliance programs usually fail: scope, exceptions, and maturity gaps

Tighter compliance controls often increase operating overhead, requiring firms to balance faster customer experience against slower but more defensible review and escalation. That tradeoff becomes especially visible when products, customer segments, or cross-border flows do not fit neatly into one rule set.

One common variation is the difference between a policy-led program and a control-led program. A policy-led program describes what should happen, but a control-led program proves how it happens in production. Regulators and supervisors usually care more about the second. Another edge case is outsourcing: if screening, case review, or blockchain analytics are handled by third parties, the firm still needs oversight of thresholds, service quality, data access, and decision ownership. A delegated process can reduce internal load, but it does not transfer accountability.

There is also an important consensus issue around Travel Rule implementation and transaction monitoring depth. Industry practice is still uneven across jurisdictions and vendors, so firms should treat interoperability claims cautiously and verify what data is actually exchanged, stored, and reviewable. The ISO/IEC 27002:2022 Information Security Controls is useful for thinking about control discipline, evidence, and operating consistency, while the ISO/IEC 27001:2022 Information Security Management helps frame the broader management system needed to keep compliance controls governed over time. The framework weakens whenever exception handling becomes informal, because informal exceptions are the fastest way to lose auditability.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.OC-01 — Organizational Context	Helps align compliance controls with the firm's regulatory operating context.
	GV.RM-01 — Risk Management Strategy	Applies because the regime requires risk-based onboarding and monitoring.
	DE.CM-01 — Continuous Monitoring	Supports ongoing transaction monitoring and alerting across customer activity.
Recommendation — Map oversight obligations into governed processes and accountable ownership across the customer lifecycle. Embed risk-based decisioning into onboarding, monitoring, and escalation thresholds. Continuously monitor transactions and alert patterns that indicate suspicious activity.
CIS Controls v8	6.3 — Access Granting	Relevant where compliance evidence depends on controlled access to systems and cases.
Recommendation — Restrict case and evidence access to approved personnel with traceable approvals.

Practitioner Guidance

What to prioritise: Build the framework around evidence-producing controls first, not policy documentation first. If a control cannot show who decided, when they decided, and what input they used, it will be hard to defend under supervisory review.

Decision rule: Treat onboarding, monitoring, and escalation as one governed workflow. If any stage is run as an isolated task or by a separate team with no shared case record, treat that as a control gap rather than an operational convenience.

What to verify: Check that exceptions are time-bound, approved, and retained with rationale. If exceptions are recurring, they should be treated as a design problem, not as individual analyst discretion.

What practitioners underestimate: The hardest part is usually not detection logic but consistency across systems and people. A firm can have sound rules and still fail if customer data, alert outcomes, and reporting evidence do not reconcile cleanly across the lifecycle.

Practitioner takeaway: The strongest compliance framework is the one that can be tested end to end, because supervisors usually challenge traceability, ownership, and repeatability before they challenge the wording of the policy.