SNAP BI Open API Compliance: The Examiner's Nine Files

SNAP compliance did not start with PBI No. 10 of 2025 and did not change on 31 March 2026. The operative rule is still PADG No. 23/15/PADG/2021 on the Implementation of the National Open API Payment Standard, signed on 16 August 2021 and effective that same day under its own Pasal 34. Every deadline it sets has closed: four dates, twelve obligations, the last one on 30 June 2025. For a compliance director or an internal audit team in 2026, the question is no longer when to comply. It is whether the functional-test minutes, the Pasal 19 procedures, the SRO recommendation letter and the board-signed commitment letter are in the folder when an examiner asks. Endpoint specifications are published by ASPI, BCA and NICEPAY. The list of documents that proves compliance is published nowhere, and that list is this article.

What changed on 31 March 2026, and what did not

PBI No. 10 of 2025 on Payment System Industry Regulation was signed on 24 December 2025 and took effect on 31 March 2026 (Pasal 186). Its Pasal 185 revokes exactly one regulation: PBI 22/23/PBI/2020. SNAP is not in it. Pasal 184 says the opposite:

Peraturan Bank Indonesia Nomor 23/11/PBI/2021 tentang Standar Nasional Sistem Pembayaran … termasuk peraturan pelaksanaannya, dinyatakan masih tetap berlaku sepanjang tidak bertentangan dengan ketentuan dalam Peraturan Bank Indonesia ini.

Here is the part most write-ups get backwards. PADG 23/15/PADG/2021 cites three PBI in its Mengingat clause — 22/23/PBI/2020, 23/6/PBI/2021 and 23/11/PBI/2021. The first was revoked on 31 March 2026 by Pasal 185. The other two are expressly preserved by Pasal 184 huruf a and huruf c. So the SNAP PADG survives, but it survives on Pasal 184 and carries the "sepanjang tidak bertentangan" qualifier — not as a free-standing rule, and not on the legal basis most English-language articles still cite. If your working paper anchors SNAP to PBI 22/23/PBI/2020, correct it before an examiner does. Fix a smaller thing in the same pass: the signature block reads "Ditetapkan di Jakarta pada tanggal 16 Agustus 2021", while secondary sources circulate 15, 17 and 20 August. Cite the signed PDF.

What genuinely changed on 31 March 2026 sits in supervision, not in the standard's content. PADG No. 32 of 2025 Pasal 239 revokes only PADG 24/7/PADG/2022, and Pasal 240 sets its own effective date at 31 March 2026. Three of its provisions change how a SNAP build gets approved:

• TIKMI becomes a basis for approval. Pasal 1 angka 16 defines TIKMI — transaksi, interkoneksi, kompetensi, manajemen risiko, dan infrastruktur teknologi informasi — as the criteria payment-system operation is judged against. Pasal 64 ayat (2) huruf d makes it a consideration in approving activity development, product development and/or cooperation: exactly the approval an Open API build needs. Pasal 236 sets each provider's first TIKMI result by Bank Indonesia no later than 1 April 2027, weighing the provider's own self-assessment.
• SNAP account linkage is classified as complex. Pasal 124 ayat (1) splits development into complex and standard; ayat (2) huruf a puts "pengembangan aktivitas, Sumber Dana, dan akses ke Sumber Dana" on the complex side. The Penjelasan to that letter lists nine examples, and item 8 reads "account linkage dengan Standar Nasional Open API Pembayaran (SNAP)". Connecting accounts over SNAP is not an internal IT change; it lands in the category carrying the heavier approval path.
• The standard belongs to Bank Indonesia. Pasal 194 ayat (1) obliges PJP, PIP and Peserta to meet the national-standard policy. Ayat (3) lets BI assign an SRO to build and manage those standards; ayat (4) keeps ownership with BI, "untuk melindungi kepentingan publik". Pasal 196 huruf a names the issuing of recommendations as part of that management — so the ASPI recommendation letter you are chasing now has a footing in two regulations at once. ASPI runs SNAP day to day; the obligation still runs to Bank Indonesia.

Who is bound, including a company that only consumes a bank's API

Pasal 1 draws a four-way split, and three of the four get misquoted often enough to be worth setting out verbatim.

Term	Pasal 1	Definition, verbatim	What it means
Penyedia Layanan	angka 5	"PJP yang menyediakan layanan Open API Pembayaran berbasis SNAP"	A licensed payment service provider on the supply side — the bank or gateway publishing the API
Pengguna Layanan	angka 6	"PJP atau pihak selain PJP yang menggunakan layanan Open API Pembayaran berbasis SNAP"	The umbrella term for anyone consuming the API
PJP Pengguna Layanan	angka 7	"PJP yang menggunakan layanan Open API Pembayaran berbasis SNAP untuk kepentingan konsumennya dan/atau dirinya sendiri"	A licensed PJP consuming someone else's SNAP API — for its customers or on its own account
Non-PJP Pengguna Layanan	angka 8	"pihak selain PJP yang menggunakan layanan Open API Pembayaran berbasis SNAP untuk kepentingan konsumennya"	An unlicensed consumer of the API — for its customers only

The asymmetry between angka 7 and angka 8 is the point. Only the licensed user gets "dan/atau dirinya sendiri"; a non-PJP is confined to "untuk kepentingan konsumennya". An insurer collecting premiums from its own policyholders over a bank's SNAP API sits squarely inside angka 8. A corporate treasury moving its own money over the same API is not covered by that limb at all — a different conversation with your bank, and a different set of contract terms.

Pasal 28 closes the gap the other way: what binds a PJP Pengguna Layanan applies mutatis mutandis to a Non-PJP one. Pasal 14 ayat (2) then puts enforcement on your bank, which must ensure its Non-PJP users apply SNAP and comply with every user-facing provision of the PADG (huruf a), and that the Open API contract with you matches the contract standard in the governance guideline (huruf b). So when a partner bank asks to redraft the contract and to see your evidence, that is not a commercial request. Refusing moves the sanction risk onto them, and that ends in termination.

Every deadline in Pasal 26: twelve obligations, four dates, all closed

Pasal 26 is usually summarised as three dates. It carries four, across seven ayat and twelve obligations, with a thirteenth in Pasal 33. Eleven of the twelve are keyed to a date of their own and sit in the table below; the twelfth, ayat (5), borrows its dates from the others and is set out underneath. None of them is open in September 2026; the last closed more than 14 months ago.

Deadline	Who	Obligation	Basis
30 June 2022	Candidate Penyedia Layanan involved in drafting SNAP	Apply SNAP to Open API already in use before the PADG took effect	26(1)a
30 June 2022	Same	Ensure its drafting-involved Non-PJP candidate users apply SNAP	26(1)b
30 June 2022	Same	Integrate its drafting-involved candidate users, PJP and Non-PJP alike	26(1)c
30 June 2022	Candidate users that are PJP and were involved in drafting	Apply SNAP to Open API already in use before the PADG took effect	26(2)
31 December 2022	All other candidate Penyedia Layanan	Apply SNAP to Open API already in use before the PADG took effect	26(3)a
31 December 2022	All other candidate users that are PJP	Same	26(4)
31 December 2022	Candidate Penyedia Layanan filing after the PADG took effect for a licence and/or approval of activity development, product development and/or cooperation using an API	Apply SNAP	26(7)
31 December 2022	Candidate Penyedia Layanan that had already filed, or were mid-process, when the PADG took effect	Apply SNAP	Pasal 33
30 June 2024	Drafting-involved candidate Penyedia Layanan	Integrate all remaining candidate users, PJP and Non-PJP, beyond those in 26(1)c	26(1)d
30 June 2024	All other candidate Penyedia Layanan	Integrate every candidate user cooperating with it	26(3)b
30 June 2025	Drafting-involved candidate Penyedia Layanan	Integrate all users that are micro, small and medium enterprises, plus non-profit institutions	26(1)e
30 June 2025	All other candidate Penyedia Layanan	Same	26(3)c

Three qualifications get dropped elsewhere. All four "menerapkan SNAP" duties are limited to "Open API Pembayaran yang sudah digunakan sebelum Peraturan Anggota Dewan Gubernur ini berlaku" — APIs already in production on 16 August 2021, not ones built afterwards. Pasal 26 ayat (5) adds the rider most action plans miss: the provider must also ensure its users adopt the SNAP pedoman tata kelola under Pasal 3 ayat (3) huruf b, by the same 26(1)c, (1)d, (1)e and 26(3)b, (3)c dates. The governance guideline, not just the technical spec. And under Pasal 26 ayat (6) Bank Indonesia notifies each drafting-involved candidate provider and PJP user of its deadline in writing, so the date binding your institution is in that letter, not in the table above. Pasal 27 lets BI set a specific policy here, weighing readiness, business-model innovation and the direction of national economic policy.

Sanctions, and how the fine is collected

Pasal 31 ayat (1) enumerates the breaches that carry licence risk: Pasal 11 ayat (4) huruf f; Pasal 14; Pasal 15 ayat (1), (2), (5) and (6); Pasal 16 ayat (1), (3) and (4); Pasal 20 ayat (2); Pasal 21 ayat (1) and (5); Pasal 22 ayat (1); Pasal 24 ayat (2) and (3); Pasal 25 ayat (3); Pasal 26 ayat (1), (2), (3), (4), (5) and (7); Pasal 29 ayat (2) and (3); and Pasal 33. Note the absence: 26 ayat (6) is not on the list, because it binds Bank Indonesia rather than the provider. The sanctions run from a written reprimand, through suspension of part or all of the activity including performance of the cooperation itself, to revocation of the PJP licence. Late quarterly reporting under Pasal 23 ayat (5) or (6) draws a monetary penalty instead, and for a provider holding a giro account at Bank Indonesia, Pasal 31 ayat (4) huruf a collects it by debiting that account directly.

The nine files an examiner asks for

Pasal 16 through 23 read as a document list, not a feature list. Build the examination folder in this order.

#	File	Minimum content	Basis
1	Test results from the SNAP Developer Site	At least one run for every Open API developed, covering positive and negative scenarios; results downloadable from the Developer Site	16(1)a, 17(1), 17(2)
2	Functional-test minutes (berita acara)	Scenarios and results with supporting documents; every system component tested end to end, internally and provider-to-user, each layer covering security testing and both positive and negative scenarios	18(1)–18(4)
3	System development, change and maintenance procedures and documentation	Eight aspects: requirements and impact analysis; design; development; internal functional testing; functional testing with the cooperating party; system security testing; implementation; preventive and corrective maintenance	16(1)c, 19
4	Verification request filed with the SRO	Attaching files 1, 2 and 3, plus any further document the SRO asks for	20(3)
5	Letter of commitment to apply SNAP	Signed by the board of directors	21(2)a, 21(3)a
6	SRO recommendation letter	Issued after verification; a precondition before any new Pengguna Layanan may be integrated	21(2)b, 23(2), 23(4)
7	SOP for assessing user eligibility	The provider's own procedure for judging whether a party may be connected	21(2)c
8	Action plan and risk-mitigation analysis	For an already-licensed PJP: target dates for integrating each Pengguna Layanan and target dates for bringing contracts into line with the governance guideline	21(3)e, 21(3)f, 21(4)
9	Quarterly periodic report	Realised integration of Pengguna Layanan, and additions of new ones	23(5), 23(6)

Two rows fail more often than the rest. File 2, because the minutes usually record positive scenarios only — Pasal 18 ayat (2) demands positive and negative scenarios at two layers, internal and provider-to-user, each with security testing alongside. And file 8, because the project team closes the action plan the moment technical integration lands, while the contract remediation in Pasal 21 ayat (4) huruf b is still open. One more trap: Pasal 21 ayat (5) requires an approval filing to name at least one candidate Pengguna Layanan per Open API, so an approval sought with no counterparty attached goes nowhere.

The public listing proves less than it looks

We read the Direktori Publikasi on the SNAP Developer Site on 2 September 2026 and counted 15 entities: Bank Central Asia, Bank Negara Indonesia, Bank Rakyat Indonesia, Bank Mandiri, Bank CIMB Niaga, Bank Permata, Bank DKI, Bank Pembangunan Daerah Jambi, Espay Debit Indonesia Koe (DANA), Visionet Internasional (OVO), GDC Multi Sarana, Harsya Remitindo, Sarana Pasar Digital, Jatelindo and Lippo Karawaci.

That is not a count of SNAP-compliant institutions. Pasal 1 angka 12 describes the Direktori Publikasi as the part of the Developer Site publishing parties who have applied the standard following verification; listing is a separate registration, and a listed party can ask to come off. The narrower statement is the more useful one anyway: the only publicly checkable SNAP directory in Indonesia holds 15 names, two of them regional development banks, and not one insurer or multifinance company.

The security controls, and one of them measured

Pasal 3 ayat (1) puts four aspects in scope — interconnection and interoperability, information-security standards, governance, and risk management — applied under ayat (4) to five API categories: registration, balance information, transaction history, credit transfer and debit transfer, plus any further category Bank Indonesia sets. The standard itself lives on the SNAP Developer Site. Read on 2 September 2026, it requires:

• An asymmetric signature, SHA256withRSA, on the B2B access-token request, with mandatory headers Content-Type, X-TIMESTAMP, X-CLIENT-KEY and X-SIGNATURE. B2B2C adds Authorization-Customer and X-DEVICE-ID, both mandatory.
• A symmetric signature, HMAC_SHA512, with AES-256 keyed on the client secret.
• An access-token life of 900 seconds — the standard's own response example carries "expiresIn":"900".
• Ten-year retention of data and logs, daily, weekly and monthly database backups, transaction-log backup.
• A hot DRC for the API management infrastructure, RTO and RPO both under one hour, replication held to the same SLA.
• Periodic audit by an independent auditor of the SNAP implementation, on the provider and the user side alike. Of the six, this is the one we would ask for first: it is the only one costing a budget line rather than a code change, and so the one most easily left out of the annual audit plan.

Our measurement: TLS on 15 published Indonesian payment API hosts, 2 September 2026

The standard requires TLS 1.3 and time-boxes the fallback. Its words: use of TLS 1.2 with the specified minimum cipher modules "hanya dapat diterapkan oleh Penyedia Layanan dan Pengguna Layanan sampai dengan tanggal 30 Juni 2026" — permitted only until 30 June 2026. That date passed 70 days before this article was published, and we have found no English-language page anywhere that mentions it.

Method. From WEBARQ's own server in Jakarta (AS396982, 34.50.126.151), OpenSSL 3.5.5, openssl s_client with SNI and the version pinned to -tls1_3 then -tls1_2, repeated twice on 2 September 2026. The hosts are public API endpoints published by the operators themselves, plus ASPI's SNAP Developer Site.

Host	Operator	TLS 1.3	TLS 1.2 still accepted
apidevportal.aspi-indonesia.or.id	SNAP Developer Site (ASPI)	No	Yes
api.bankmandiri.co.id	Bank Mandiri	Yes	No
sandbox.bca.co.id	BCA	Yes	Yes
partner.api.bri.co.id	BRI	Yes	Yes
api.permatabank.com	Bank Permata	Yes	Yes
api.cimbniaga.co.id	Bank CIMB Niaga	Yes	Yes
api, dev, staging and www .nicepay.co.id (4 hosts)	NICEPAY	Yes	Yes
api.doku.com	DOKU	Yes	Yes
api.midtrans.com	Midtrans	Yes	Yes
api.xendit.co	Xendit	Yes	Yes
api.klikbca.com	BCA	Connection reset before the handshake (errno 104)
api.bni.co.id	BNI	Connection timed out

Of the 13 hosts that completed a handshake, 12 still accept TLS 1.2 more than two months after the date the standard sets for withdrawing it. The one exception, answering with TLS alert 70, protocol version, is api.bankmandiri.co.id.

The least comfortable row is the first. ASPI's own SNAP Developer Site does not serve TLS 1.3. We pinned four versions against it: TLS 1.0, 1.1 and 1.3 were all refused, and only TLS 1.2 negotiated, on ECDHE-RSA-AES256-GCM-SHA384. That is the site where Pasal 16 ayat (1) huruf a obliges every Penyedia Layanan and PJP Pengguna Layanan to run its testing.

Four qualifications, because a measurement without them is not evidence. TLS is one control among many: passing proves nothing about compliance, and failing is a deviation on the one control measurable from outside. Production endpoints usually sit behind IP allow-listing — which the same standard requires — so a public host is not necessarily the host serving contracted partners, and the reset on api.klikbca.com is consistent with IP restriction rather than a finding. The TLS clause binds Penyedia Layanan and Pengguna Layanan, while the Developer Site's operator is the standard's manager, not a party to it. And that accepting TLS 1.2 after 30 June 2026 amounts to a deviation is our reading of the clause — we found no enforcement statement from Bank Indonesia or ASPI either way. One vantage point, one date: repeat it from your own network before it goes into a working paper.

Five clocks, and all of them run 3x24 hours

The SNAP Pedoman Tata Kelola v1.0 (August 2021) carries operating deadlines that appear on no English-language page discussing SNAP. Four are written-notification clocks, all set at 3x24 hours from the moment the event becomes known; the fifth is a consent clock at the same interval.

Trigger	What the clock requires	Who must be told
Consumer withdraws consent	Withdrawal takes effect within 3x24 hours of the request being received and verified	Between provider and user; the request may arrive through either side
Data-protection failure (kegagalan pelindungan data)	Written notice, electronic or otherwise, within 3x24 hours of the event becoming known, alongside an incidental report to BI's payment-system supervision unit	Affected consumers; parties cooperating in the Open API service; and/or the competent authority
Fraud or abnormal transactions materially affecting continuity of payment processing, or causing direct consumer loss	Incidental report to BI, then written notice within 3x24 hours	The same three groups
Indication of abnormal transactions detected by the Penyedia Layanan	Suspend the Open API service, file the incidental report, notify within 3x24 hours	The same three groups
Indication of abnormal transactions detected by the PJP Pengguna Layanan	The same three steps	The same three groups; a Non-PJP user reports through its provider

The breach clock meets its twin in UU No. 27 of 2022 on Personal Data Protection, promulgated 17 October 2022, whose Pasal 46 ayat (1) requires written notice within 3 x 24 hours to the data subject and the supervisory body; the two-year transition in Pasal 74 ended on 17 October 2024. One API integration, two authorities, the same clock. The guideline also requires a data-protection function or a named Data Protection Officer, and caps complaint resolution at 20 working days plus one 20-working-day extension.

The same guideline sets the minimum clauses for an Open API service contract — nine, from Para Pihak through to Penyelesaian Perselisihan — plus optional ones covering transaction SLAs, service fees and taxes, and data reconciliation. That is what Pasal 21 ayat (4) huruf b means by contract remediation. If your agreement with a partner bank was signed before 2021 and has never been reopened, that is where the finding is.

One architectural decision is routinely treated as configuration. Pasal 15 ayat (5) requires the Penyedia Layanan to stop transaction processing and/or data access when authorisation under ayat (1) or consumer consent under ayat (3) fails. A system that lets a transaction proceed with consent status "unknown" breaches that clause, and it shows up in the logs.

What a compliance director and internal audit should do this quarter

1. Ask the team holding the payment integrations for the folder of nine files above. If files 2 and 3 cannot be produced within a day, that is the finding.
2. Find the written notification from Bank Indonesia contemplated by Pasal 26 ayat (6). The date in that letter binds your institution, not the table above.
3. Check whether the Pasal 21 ayat (4) huruf b action plan — contract remediation, not technical integration — has been closed for every Pengguna Layanan.
4. Put a periodic independent audit of the SNAP implementation into this year's audit plan if it is not already there.
5. Test the TLS posture of your own endpoints and your partners', and keep the dated output.

One thing needs saying plainly. WEBARQ has never implemented SNAP for any client, and no project record of ours mentions SNAP, BI-FAST or QRIS. What we can show is the work next door: at CGS International, online securities account opening with OCR on the web form, video-call and self-verification, linking banks, CGS-CIMB, KSEI and DUKCAPIL with compliance as an acceptance criterion; at MSIG, automated e-policy generation wired into core financial systems for policy sales and premium collection. Regulated onboarding and core-system integration — the shape of a SNAP migration inside an institution that is already running. Not SNAP experience, and we will not call it that.

For which rail should carry which payment, see our comparison of Indonesian payment gateways against BI-FAST, QRIS and virtual accounts. For the service layer underneath APIs like these: what a cloud-native application is, cloud-native application development and website development.

Every regulatory quotation was read directly from the issuing body's own document at bi.go.id and peraturan.bpk.go.id on 2 September 2026, and the SNAP technical and security standard from ASPI's Developer Site the same day. The TLS measurement is our own, run that day; its method and limits are stated above. Research and drafting for this article were AI-assisted and verified against primary sources by the WEBARQ team.