What Is Encryption? 16 Indonesian Rules and What It Can't Stop

Encryption is the process of turning readable data (plaintext) into ciphertext with an algorithm and a key, so that only a key holder can read it back. Of the 16 Indonesian instruments we read on 30 October 2026, only Article 15(2) of Permenkominfo 20/2016 requires it in general terms, and only for stored personal data. Only the SNAP technical standard names a TLS version and an algorithm. Encryption protects the pipe, not the customer who is talked into sending money down it: all 11 consumer bank hosts we tested refuse TLS 1.0 and 1.1, while Indonesia's Anti-Scam Centre has logged 702,342 scam reports.

Data encryption is one guarantee, not five

Encryption on its own gives you confidentiality. Google's AI Overview for "what is encryption", fetched from Indonesia on 30 October 2026, credits it with four jobs: confidentiality, integrity, authentication and non-repudiation. The last three come from other primitives, and an architect or examiner needs them kept apart.

In a bank channel, the usual examples are AES-256 for the database (data at rest), TLS 1.3 from the app to the server (data in transit), and end-to-end encryption on WhatsApp. That last one means a scammer's message also arrives intact. An encrypted channel says nothing about whether the sender is honest.

Where Indonesian rules write the word "encryption"

For readers outside Indonesia: POJK and SEOJK are regulations and circulars from the financial services authority, OJK. PBI and PADG come from Bank Indonesia. Perban BSSN comes from the national cyber agency, and Permenkominfo from the communications ministry, now Komdigi.

We counted the word "enkripsi", including "terenkripsi" and "dienkripsi", in each instrument's PDF text with an automated search (pypdf, whitespace normalised). Dates are issue or promulgation dates. Two figures carry a caveat. BPK's copy of UU 27/2022, the personal data protection law (UU PDP), is an OCR scan, so its zero isn't confirmed against a born-digital copy. We read PP 33/2026 from a third-party transcription by Meridian Hukum (SHA-256 begins edb207c89259), because we found no copy hosted by the issuer. We paraphrase it, and its wording needs rechecking against an official copy before anyone quotes it.

One explicit duty, and how far it reaches

"Data Pribadi yang disimpan dalam Sistem Elektronik harus dalam bentuk data terenkripsi." (Permenkominfo 20/2016, Article 15(2))

In English: personal data stored in an electronic system must be in encrypted form. The sentence covers data at rest only and names no algorithm or key length. Komdigi's legal database still marks the regulation in force, and Article 36(1) carries administrative sanctions.

PP 33/2026 complicates this. It was promulgated on 16 July 2026, and Article 225 starts it six months later, which we compute as 16 January 2027, so it wasn't in force when we wrote this. Article 123(2)(a) lists pseudonymisation, encryption of personal data "and/or" other technical steps, which makes encryption an option there rather than a stand-alone duty. Once in force, Article 224 keeps existing data protection rules alive where they don't conflict with it. Whether that "and/or" softens the older regulation's "must" is an open question. We found no answer, so don't drop an encryption control on the reading that it's now optional.

The data protection law never says encryption

One top-10 page for the Indonesian query "enkripsi adalah", when we checked on 30 October 2026, calls encryption a key way to meet the security standards UU PDP requires. The word isn't in the law. Article 35 asks for operational technical steps, Article 39(2) asks for a security system, and the elucidation of both reads "Cukup jelas" (self-explanatory).

There's a consequence European readers will spot. UU PDP has no encrypted-data exception to the 3 x 24 hour notification in Article 46, whereas GDPR Article 34(3)(a) has one for notifying data subjects. Our reading: stolen ciphertext could still trigger notification, because the elucidation of Article 46(1) covers unauthorised access to data "dikirim, disimpan, atau diproses" (sent, stored or processed). We found no ruling, so take legal advice before writing that into an incident playbook.

OJK's controls sit in an annex, and its example is SSL

For commercial banks, the auditable duties are in Annex I of SEOJK 29: "metode pengendalian kriptografi" (cryptographic control methods, 2.3.d, p. 38), encryption for wireless, mobile devices and external storage (2.f item 7, p. 64), and authentication "melalui saluran terenkripsi" (over an encrypted channel, 2.g item 11, p. 67). There's no TLS version, algorithm or key length.

PADK 1/2026, in force since 1 March 2026, gives as a network standard example "misalnya penggunaan Secure Socket Layer (SSL)" (p. 48). The IETF ruled "SSLv3 MUST NOT be used" in RFC 7568 back in June 2015. We read "SSL" here as loose shorthand for TLS, not an instruction to run a retired protocol. A bank's internal policy should still name a TLS version, because OJK's text doesn't. Non-banks get less: the only occurrence in SEOJK 22/2021 is "menyimpan password secara aman (terenkripsi)", storing passwords securely (p. 24).

Perban BSSN 8/2020 isn't entirely silent. Item 1.4 of its annex (p. 26) offers "[C] Tidak ada penggunaan teknik kriptografi" (no use of cryptographic techniques) as an answer in the risk categorisation questionnaire. That's a scoring option, not a control. Article 9 makes SNI ISO/IEC 27001 an outright requirement only for strategic systems. High-tier systems may apply it and/or another standard set by BSSN, and low-tier systems it or that other standard. Annex A of ISO/IEC 27001:2022 includes a cryptography control, so for systems that do apply 27001, the practical reference is the Statement of Applicability behind the certificate.

SNAP: the TLS 1.2 deadline has passed

The SNAP Technical and Security Standard v1.0.2 (September 2024) binds through Article 14(1) of PADG 23/15/PADG/2021, which requires payment Open APIs to be SNAP-based. Item 2.1.10 (p. 28) asks for TLS 1.3. Negotiating down to TLS 1.2 with four DHE/ECDHE-RSA AES-GCM suites "hanya dapat diterapkan oleh Penyedia Layanan dan Pengguna Layanan sampai dengan tanggal 30 Juni 2026": service providers and users may do so only until 30 June 2026. Item 2.1.9 (p. 27) names SHA256withRSA, HMAC_SHA512 and AES-256.

For scale, NIST SP 800-52 Rev. 2 required TLS 1.3 support on US government TLS servers and clients by 1 January 2024. SNAP goes further on paper, since it ends the fallback rather than only adding the new version. It's also the only cryptographic line among our 16 instruments with a date on it, and we'd treat it as a deadline, not a footnote. We didn't check whether a PADG amendment changed the date, and we found no newer version on the portal. The compliance context is in our SNAP evidence guide.

Our measurement: TLS on bank hosts, 30 October 2026

We ran read-only handshakes with OpenSSL 3.5.8 from svr.webarq.com on 30 October 2026 at 15:42 UTC. The sample was 11 consumer hosts and 13 API hosts. api.bni.co.id and apidev.bni.co.id didn't answer, so we have no data for BNI's API. api.btn.co.id didn't resolve and isn't counted.

Three API hosts serve TLS 1.3 only: api.klikbca.com, api.bankmandiri.co.id and api.danamon.co.id. The other eight, two sandbox hosts among them, still accept TLS 1.2 four months after the SNAP date. These hosts aren't proven to be SNAP endpoints, so we call none of them non-compliant.

Static RSA is accepted by ib.bri.co.id, bni.co.id and cimbniaga.co.id on the consumer side, and by partner.api.bri.co.id, sandbox.partner.api.bri.co.id, api.cimbniaga.co.id and api.ocbc.id on the API side. These suites have no forward secrecy: if the server's private key leaks, recorded traffic can be opened later. This is one vantage point on one day, and a host may behave differently for other clients. Our API list differs from our 15-host survey of 2 September, so don't compare the totals.

Three ways it fails, and the third isn't about cryptography

1. The crypto is weak. An outdated algorithm or protocol, such as SSLv3. The TLS table above measures this layer.
2. The key is stolen. Through admin access, staff phishing or poor key management. Encryption only moves the question to who holds the key: a CDN that decrypts TLS at the edge, a cloud provider, or malware on the phone, which runs at the end where the data is already decrypted.
3. The crypto works perfectly, and the legitimate customer sends the money. UK regulators call this authorised push payment fraud: nothing is hacked, the transfer instruction is genuine, and the connection stays encrypted until the money has gone.

None of the "enkripsi adalah" pages we read covers case 3, and nor does the AI Overview for "what is encryption". From 22 November 2024 to 30 September 2026, Indonesia's Anti-Scam Centre (IASC, in OJK's September 2026 release) received 702,342 reports, blocked 702,833 accounts and Rp811.1 billion, and returned Rp207.16 billion from accounts at 24 banks. Those figures cover all transaction scams, not phishing alone, and the release gives no total loss. All 11 of our consumer hosts refuse TLS 1.0 and 1.1. When an examiner asks about scam losses and the bank says "everything's encrypted", that's a true answer to the wrong question.

The relevant controls sit on other rows. SEOJK 29 Annex I.c item 2.g covers OTP "untuk transaksi yang berisiko tinggi", for high-risk transactions (item 4), IP reputation (item 5), and MFA "untuk akses data sensitif", for access to sensitive data (item 7). SNAP has a fraud detection system section (pp. 30-31), which isn't encryption. Even SNAP's second factor, "SMS TOTP dengan 6 digit- numerik dengan durasi 5 menit" (a six-digit SMS code valid for five minutes, item 2.1.8), can be handed to a scammer by the customer. On the lure side, our phishing article explains why the HTTPS padlock proves only the connection. Once the money's gone, the incident lands in codes 303 and 305 of POJK 12/2024.

What the CTO, CISO and compliance need to decide

• Write your own crypto profile. Outside SNAP, no regulator sets one. Name the minimum TLS version, cipher suites, at-rest algorithm, key length and the owner of key rotation.
• Map API hosts to SNAP. Mark which are SNAP endpoints, and prove TLS 1.2 is closed or that the exception is written down.
• Inventory who holds plaintext. Record every decryption point, including CDN, WAF and cloud provider.
• Split the budget. Crypto controls answer cases 1 and 2. Case 3 needs transaction friction, detection and channel controls.
• Prepare two Article 46 scenarios. One where ciphertext is stolen without the key, one where the key goes too.

Disclosure: none of WEBARQ's 13 published case studies or 201 portfolio entries records encryption, TLS or key-management work. So treat this piece as our reading of the rules and our own measurements, not as a delivery record. Settle the decisions above before a mobile app development or cloud-native application development project starts, not after.