OJK AI Governance Compliance

For regulatory scope and the relationship between OJK guidance, UU PDP, and Bank Indonesia rules, start with the Indonesia AI governance overview. This page focuses on technical implementation.

Community vs Enterprise: what you can run where

The community build gives you the cross-framework foundations this page relies on: audit logging, policy enforcement, and PII/data detection. The regulator-specific workflow modules and APIs described here (the compliance registry, regulatory reports and exports, readiness/assessment surfaces, retention controls, and kill-switch APIs, where a framework has them) are Evaluation and Enterprise capabilities. The Community, Evaluation, and Enterprise columns in the capability table below are authoritative for exactly what each item needs. A higher-limit self-hosted evaluation is available under the free 90-day Evaluation License.

OJK (Otoritas Jasa Keuangan) has layered its AI governance expectations over two instruments: the binding POJK 11/POJK.03/2022 on IT implementation by commercial banks, and the April 2025 AI Governance for Indonesian Banking guidance ("pedoman"). Combined, these set expectations for AI systems used in Indonesian commercial banking, P2P lending platforms (LPBBTI under POJK 10/POJK.05/2022), and financial services consumer protection workflows under POJK 22/2023.

Pedoman vs POJK

The April 2025 AI Governance document is supervisory guidance ("pedoman"), not a binding regulation (POJK). Its prescriptive weight is supervisory expectation, not statute. OJK may operationalize specific provisions through future POJK or circulars. This page reflects the guidance as published; check the OJK regulations page for updates.

caution

This page is engineering guidance for teams building governed AI on AxonFlow. It is not legal advice. Validate the regulatory mapping with your legal and compliance teams before relying on it for OJK audits or supervisory interactions.

The two OJK instruments that apply today

1. POJK 11/POJK.03/2022 - IT implementation for commercial banks (binding, in force)

POJK 11/POJK.03/2022 requires commercial banks to implement IT governance, risk management, and internal controls covering outsourced technology - including AI systems. Key provisions:

• IT governance must be approved at the board level
• Technology risk management must cover operational risk, data security, and outsourcing
• Internal audit must include IT audit procedures for systems handling customer data
• Outsourced technology providers are subject to right-to-audit clauses

2. April 2025 AI Governance guidance (supervisory expectation)

The OJK AI Governance for Indonesian Banking guidance establishes three pillars for AI lifecycle governance:

Pillar	OJK expectation	AxonFlow coverage
Reliability	Model accuracy monitoring, drift detection, testing before deployment	Policy enforcement on every LLM + MCP call; audit trail captures decision chain and model outputs
Accountability	AI Committee, defined roles (model owner, data steward, model validator), clear escalation paths	Audit trail with user_id, policy_id, and decision_id for attribution; HITL approval gates for material decisions
Human oversight	Proportionate human review for customer-impacting decisions, override capability	HITL approval queues (Evaluation/Enterprise); circuit breaker for emergency shutdown

The guidance also names specific risks for generative AI: deepfakes, black-box models, algorithmic bias, hallucinations, over-reliance on AI outputs, and cyber threats. It expects transparency proportionate to risk, drift and concept-drift monitoring, and vendor right-to-audit provisions.

OJK AI Code of Ethics (refreshed 2025)

Six principles: Pancasila-based, beneficial, fair-and-just, accountable, transparent-and-explainable, resilient-and-secure. Extended in the 2025 refresh to cover generative AI hallucination and sensitive-data leakage risks.

A concrete example: Indonesian bank customer-service copilot on n8n with AxonFlow governance

A commercial bank operating under OJK supervision deploys an AI customer-service copilot through n8n workflows. The copilot handles balance inquiries, product recommendations, and complaint routing - all of which touch customer NIK, NPWP, and bank account data.

What OJK asks the bank to demonstrate:

• POJK 11/2022 IT governance: the AI system is disclosed in the bank's IT audit, with board-level approval for its deployment and risk classification.
• AI Governance guidance - reliability: the copilot's model outputs are monitored for accuracy and drift; AxonFlow's policy enforcement catches hallucinated financial advice before it reaches the customer.
• AI Governance guidance - accountability: the bank has designated a model owner and data steward; every copilot interaction is traceable through AxonFlow's audit trail with user_id and decision_id.
• AI Governance guidance - human oversight: material decisions (credit recommendations, complaint escalations) go through HITL approval gates; the bank can demonstrate the review trail for any OJK inquiry.

How it maps to AxonFlow tiers:

Need	Community	Evaluation	Enterprise
NIK / NPWP / bank-account detection on inbound customer data	System policies (sys_pii_indonesia_nik, sys_pii_indonesia_npwp_*, bank-account patterns) - pattern-based, ~0.7 confidence	Same	Same + province-code + checksum validation (~0.95 confidence)
Policy enforcement on every LLM + MCP call (POJK 11/2022 IT governance)	Yes	Yes	Yes
Full audit trail with decision chain (AI Governance accountability pillar)	Yes (3-day retention)	Same (14-day)	Same + 10-year retention (AuditRetentionDays=3650)
HITL on material customer-impact decisions (AI Governance human-oversight pillar)	Can emit require_approval decisions; no queue	HITL approval queue (24h expiry, 100 pending cap)	Production HITL queue + portal
OJK audit export for supervisory review	Not provided	Not provided	POST /api/v1/ojk/audit/export - structured export for OJK review
Retention posture proof (POJK 11/2022 data-handling audit)	Not provided	Not provided	GET /api/v1/ojk/audit/retention - per-data-type retention status
OJK readiness dashboard	Not provided	Not provided	GET /api/v1/ojk/audit/readiness - readiness score across 3 frameworks
UU PDP breach notification (Art. 46)	Not provided	Not provided	POST /api/v1/ojk/breach/notify - generates a draft with mapped Art. 46 fields and deadline tracking
Cross-border transfer logging (UU PDP Art. 56)	Not provided	Not provided	data_residency + transfer_basis fields in audit logs
OJK kill switch for unsafe AI behavior	Not provided	Not provided	Global / organization / system scope shutdown

What Community covers

Community gives you a credible starting point for OJK-relevant engineering work:

• audit logging with decision chain and policy attribution
• system and tenant policy enforcement on every LLM and MCP call
• Indonesia-relevant PII protection: NIK, NPWP (legacy 15-digit and new 16-digit), Indonesian mobile (+62), and bank-account patterns for BCA, Mandiri, BRI, and BNI - 8 detection patterns total on the pii-indonesia category
• governed LLM and MCP execution paths that are straightforward to review

Community PII detection is pattern-based with approximately 0.7 confidence. The patterns validate structural format (digit count, prefix ranges, context anchors) but do not perform province-code lookups or check-digit validation. Enterprise adds those validations and raises confidence to approximately 0.95.

Industry playbook

Commercial banks (POJK 11/2022)

The concrete flow above. Community covers policy + audit; Evaluation adds the HITL queue for material-decision review; Enterprise adds the structured OJK audit export and readiness dashboard. POJK 11/2022's IT-audit requirement is why the audit trail matters: when a regulator asks how AI decisions are governed, the bank needs to reconstruct what the model saw, what it produced, and who approved it.

P2P lending platforms (POJK 10/POJK.05/2022)

LPBBTI platforms deploy AI for credit scoring, borrower matching, and risk assessment. POJK 10/2022 requires IT governance for these platforms with specific provisions around data protection and outsourcing risk. AxonFlow's policy enforcement and PII detection are directly relevant: NPWP and NIK appear in every credit application, and the audit trail captures the decision chain from application intake through disbursement.

Payment service providers (PBI 23/6/PBI/2021)

Payment service providers regulated by BI also fall under OJK consumer protection rules through POJK 22/2023. See the BI Payment System Compliance page for the BI-specific requirements; the OJK overlay adds consumer-complaint handling and market-conduct supervision.

For the cross-framework view of regulated API families, use the Enterprise Compliance API Surface.

Enterprise Operating Workflow

The licensed workflow surface below is included here so engineers can evaluate both the community baseline and the production operating model from one page.

AxonFlow Enterprise includes a dedicated OJK module for audit-centric regulatory workflows aligned with Indonesian banking supervision. The module covers OJK AI Governance (April 2025 guidance), UU PDP (Law 27/2022), and BI payment system (PBI 23/6 and 23/7) frameworks through a unified API surface.

Requires Enterprise license.

caution

This guide is engineering guidance for teams operating governed AI on AxonFlow. It is not legal advice. Validate the regulatory mapping with your legal and compliance teams before relying on it for OJK audits or supervisory interactions.

What the current module covers

The OJK module registers eight routes:

Route	Method	What it supports
/api/v1/ojk/audit/export	POST	Create an OJK audit export
/api/v1/ojk/audit/export/{id}	GET	Inspect export status and metadata
/api/v1/ojk/audit/retention	GET	Check retention posture by data type
/api/v1/ojk/audit/readiness	GET	Return readiness score and checks
/api/v1/ojk/breach/notify	POST	Generate UU PDP Art. 46 breach notification
/api/v1/ojk/breach/acknowledge	POST	Record authority receipt for a submitted breach
/api/v1/ojk/breach/evaluate-deadlines	POST	Flip lapsed, never-submitted breaches to overdue
/api/v1/ojk/dashboard	GET	Return a combined compliance view

Identity handling:

• Every OJK route is scoped to the caller's organization. X-Org-ID is the identifier; on a deployment fronted by the AxonFlow agent it is set from the cryptographically validated client credential, so a caller cannot choose it.
• X-Tenant-ID is accepted only when X-Org-ID is absent. That fallback exists for single-identifier deployments, where the two values are the same. It never widens scope: when both headers are present, the organization wins.
• A request with neither header (or with a whitespace-only value) is refused with HTTP 400 missing_org. No query runs with a blank scope.

Upgrading from an earlier release

Before this change the module resolved X-Tenant-ID first and used it wherever an organization was expected. On a deployment where the two identifiers differ, breach-notification rows written under the old behaviour are stored under the tenant value and will not be visible to the org-scoped read. There is no reliable automated mapping (the row records the same value in both columns), so if you have existing ojk_breach_notifications rows, re-key them to your organization identifier before relying on the export.

When teams use this module

The OJK surface is useful for:

• commercial banks preparing for OJK supervisory review of AI systems under POJK 11/POJK.03/2022
• compliance teams needing structured audit evidence aligned with the April 2025 AI Governance guidance pillars
• platforms needing UU PDP breach-notification workflow with Art. 46 required fields and 72-hour deadline
• payment service providers preparing IS-audit evidence for BI review under PBI 23/6
• teams running cross-border AI workloads that need to log data-residency and transfer-basis for UU PDP Art. 56

Core workflow

The typical operating loop is:

1. Route governed traffic through AxonFlow so decisions, policy checks, PII detections, and LLM activity are logged
2. Generate an OJK export for a period, tenant, or incident window
3. Verify retention status for the relevant record classes
4. Review readiness findings and close gaps before a supervisory review
5. Use the breach-notification endpoint when a data incident requires Art. 46 notification

Export audit data

The export request takes a date window, an output format and a framework label.

start_date and end_date are dates (YYYY-MM-DD), not timestamps. The window is inclusive of the whole final day, in UTC at both ends: a request for 2026-08-03 covers 2026-08-03T00:00Z to 23:59Z, which is 07:00 to 07:00 WIB (UTC+7), not local midnight to midnight. Audit timestamps are written in UTC, so a UTC window slices them without an offset artefact. A date range longer than five years is refused.

curl -X POST http://localhost:8081/api/v1/ojk/audit/export \
  -H "Content-Type: application/json" \
  -H "X-Org-ID: your-org-id" \
  -d '{
    "start_date": "2026-01-01",
    "end_date": "2026-03-31",
    "format": "json",
    "framework": "OJK_AI_GOVERNANCE"
  }'

The format field does not change the response body

format is accepted as json (default), csv or xml, but this endpoint produces only JSON. When you ask for csv or xml the response reports format: json (what the body actually is), echoes your request in requested_format, and explains the difference in format_note. It will not label a JSON body as csv. Rendered output is delivered by the compliance-report facade, not this endpoint.

The framework field accepts OJK_AI_GOVERNANCE, UU_PDP, BI_PJP or OJK_BI_COMBINED, and it changes what the report contains - see what each framework returns below. When data_types is omitted (the usual case) the framework selects the sections.

data_types may be given explicitly to override that selection: policy_violations, llm_calls, decision_chain, hitl_oversight, pii_redactions, cross_border_transfers, breach_notifications, or all. An explicitly requested section is always served; if the selected framework does not consider it in scope, the section is returned with in_framework_scope: false and a note, rather than being dropped.

A data type the platform does not recognise produces an explicit per-section error in the response summary. It is never silently omitted.

What each framework returns

Framework	Sections, in report order	Instrument
OJK_AI_GOVERNANCE	policy violations, LLM calls, decision chains, HITL oversight	OJK AI governance guidance (April 2025); POJK 11/2022
UU_PDP	PII redactions, cross-border transfers, breach notifications, policy violations	UU PDP Law 27/2022 (Pasal 56, Art. 46)
BI_PJP	decision chains, HITL oversight, PII redactions, cross-border transfers, breach notifications	PBI 23/6/PBI/2021
OJK_BI_COMBINED	all seven sections	the union of the above

BI_PJP deliberately omits the model-activity register (llm_calls): it is not a PBI 23/6 requirement. OJK_AI_GOVERNANCE deliberately omits the personal-data sections; request UU_PDP or OJK_BI_COMBINED for those.

Every export also carries a framework_summary block naming the instrument and mapping each regulatory pillar to the sections that evidence it.

Reading the response: report_state

Every section, and the summary as a whole, carries an explicit report_state:

Value	Meaning
populated	The section was served and has at least one record
enabled_empty	The section was served and the honest answer is zero records for this organization and window
not_available	The section could not be served at all. Always paired with an error naming the cause and an error_kind of section_not_implemented, store_absent or query_failed - "this deployment structurally cannot produce this evidence" and "that read failed once" are different things to tell a regulator

Read report_state, not the presence of a JSON key. An empty section renders as enabled_empty; it must never be read as "the module is not enabled", which is a state the backend cannot produce.

Sections are capped at 100,000 records. A section that reaches the cap says so in its note, so a truncated export never reads as a complete one.

What the PII redactions section contains

The pii_redactions section is sourced from the Indonesia PII detector running on the gateway, Decision API and MCP response planes. Each record carries:

Field	Meaning
pii_type	nik, npwp_legacy, npwp_new, phone_indonesia, bank_bca, bank_mandiri, bank_bri, bank_bni
ojk_category	national_identity, tax_identifier, contact_information, financial_account
masked_value	The masked form only
action	blocked (the request was refused), redacted (this plane masked the value before the content moved on), redaction_required (a policy decision point determined redaction was required and told the PEP - it masked nothing itself), or detected (observed under a warn/log posture, content unmodified)
plane	gateway, decision or mcp
decision_id / correlation_id	Join keys back to the decision row that carries the verdict

The detected action is the one an auditor most needs: under a warn or log posture the content is forwarded unchanged, and this record is the only evidence that Indonesian personal data was present and was not masked.

redaction_required and redacted are deliberately different values. Only the MCP response plane mutates content itself, and it records redacted only when the mask actually changed something. The gateway pre-check and /api/v1/decide are policy decision points: they set requires_redaction or emit a redact_pii obligation and the calling SDK acts. Recording those as redacted would tell a regulator the platform masked a value it had only asked someone else to mask.

Raw detected values are never stored and therefore can never be exported. The store holds the detector's masked form only; neither the matched text nor the surrounding context window is written.

This section requires enterprise migration 137. On a deployment where it has not been applied the section reports not_available with an error naming the migration - not an empty list.

Check export progress

curl http://localhost:8080/api/v1/ojk/audit/export/exp_67890

The response includes export_id, status, framework, summary metadata, and, for larger exports, a download_url plus expiry metadata when cloud storage is configured.

Check retention posture

The retention endpoint returns per-data-type retention status, including configured days, oldest and newest record timestamps, total and archived record counts, storage usage estimates, and compliance status.

curl http://localhost:8080/api/v1/ojk/audit/retention

This is the endpoint compliance teams should use before claiming an audit window is fully defensible. For Indonesian banking, the 5-year minimum retention floor applies when AXONFLOW_COMPLIANCE_REGION includes ID.

Check readiness before a supervisory review

curl http://localhost:8080/api/v1/ojk/audit/readiness

The readiness response is built around:

• ready - boolean overall readiness
• score - 0-100, computed over the checks that could be measured
• checks - one entry per dimension, with a status and what was observed
• measured_checks / unknown_checks - the score's denominator, made visible
• recommendations - actionable items to close gaps

Every check queries the state it names, or reports unknown. A dimension the platform cannot observe from this deployment is never reported as a pass.

Check	What is measured	Verdicts
Data Retention	The effective retention configuration against the 1825-day (5 year) Indonesian floor	pass / fail
PII Detection	Enabled pii-indonesia policy rows visible to the organization, and detection events recorded in the last 90 days	pass (policies and events) / warning (configured, no events in the window) / fail (no policy visible)
Human Oversight	Oversight requests queued for the organization in the last 90 days, and how many were reviewed	pass (reviewed) / fail (queued and none reviewed) / warning (nothing required oversight)
Audit Logging	Audit records for the organization in the last 90 days	pass / warning (readable, no rows)
Breach Notification	Recorded breaches past the 3x24 hour window without a timely submission	pass / fail (any overdue)

Scoring: a pass counts 1, a warning 0.5, a failure 0, and an unknown check scores zero while still counting in the denominator. An unobservable dimension drags the score down; it never inflates it. measured_checks and unknown_checks expose the split. ready requires no failures, no unknowns, and a score of at least 80.

A warning is not a failure. "The control is configured and this window contains no evidence that it fired" is a legitimate state for a quiet period, and the check says exactly that rather than claiming either success or breach.

Generate a breach notification (UU PDP Art. 46)

When a data incident requires notification under UU PDP Art. 46, the breach endpoint generates the notification template:

curl -X POST http://localhost:8080/api/v1/ojk/breach/notify \
  -H "Content-Type: application/json" \
  -H "X-User-ID: compliance-lead-1" \
  -d '{
    "data_types_involved": ["nik", "npwp", "bank_account"],
    "discovery_timestamp": "2026-03-15T14:30:00Z",
    "estimated_subjects_affected": 1200,
    "remediation_steps": [
      "Revoked compromised API credentials",
      "Enabled additional PII redaction policies",
      "Initiated forensic audit of affected tenant"
    ]
  }'

The response includes:

• notification_id - unique identifier for tracking
• notification_deadline - calculated as 72 hours from discovery_timestamp
• recipient - currently "MOCDA" (until the DPA is constituted)
• status - draft, sent, or acknowledged
• All Art. 46 required fields pre-populated for review before sending

OJK kill switch

The kill switch provides emergency shutdown at three scopes:

• Global - stops all AI processing across the organization
• Organization - stops AI processing for a specific tenant or business unit
• System - stops a specific AI system (identified by system_id)

This maps to the OJK AI Governance guidance's human-oversight pillar requirement for override capability on AI systems that impact customers. The kill switch is implemented through the circuit breaker API - see HITL & Circuit Breaker API Reference for the POST /api/v1/circuit-breaker/trip endpoint.

Dashboard

curl http://localhost:8080/api/v1/ojk/dashboard

The dashboard returns a combined compliance view for the caller's organization. Every count is derived from an organization-scoped query:

Field	Derivation
compliance_score	The readiness score, so the headline and /audit/readiness cannot disagree. readiness_unknown_checks reports how many dimensions could not be read; when it is non-zero, compliance_score:partial appears in unavailable
total_audit_records	Audit records for the organization, all time
active_policies	Enabled Indonesia-PII policy rows the organization can see (the global system tier plus its own)
recent_violations	Refusing or modifying decisions (blocked, redacted, needs-approval) in the last 30 days
indonesia_pii_events	Indonesia PII detection events in the last 30 days
breach_notifications / overdue_breach_notifications	Recorded breaches, and how many are past the 3x24 hour window

A count that cannot be derived on this deployment is returned as -1 and named in an unavailable list. "We could not measure this" and "there were none" are different answers to a regulator, so they are different values here.

Recommended operating pattern

For production teams running banking or payment workloads under OJK supervision:

Cadence	Action	Endpoint
Weekly	Check readiness score and close gaps	GET /api/v1/ojk/audit/readiness
Monthly	Review dashboard for compliance posture	GET /api/v1/ojk/dashboard
Quarterly	Generate audit export for supervisory review	POST /api/v1/ojk/audit/export
Quarterly	Verify retention posture	GET /api/v1/ojk/audit/retention
On incident	Generate breach notification within 72h	POST /api/v1/ojk/breach/notify
On incident	Activate kill switch if unsafe behavior detected	Kill-switch API

Related docs

• Compliance Overview
• Enterprise Compliance API Surface
• BI Payment System Compliance
• UU PDP (Indonesia Data Protection) Compliance
• PII Detection
• Human-in-the-Loop