For founders and product teams choosing who builds a fintech product in Indonesia — what a fintech-aware developer actually has to handle, and when you need a specialist.
Building a fintech product in Indonesia in 2026 isn't just an engineering problem — it's a regulatory one wearing an engineering costume. Two different regulators govern two different halves of fintech, data-localization rules can force where your servers live, and the wrong architectural shortcut can mean a rebuild the moment a bank partner, OJK or Bank Indonesia asks a question your system was never designed to answer. This guide is for founders and product teams choosing who builds it: what a fintech-aware developer in Indonesia actually has to handle, and when you need a specialist versus a strong generalist plus a compliance advisor.
Note: This is not legal or regulatory advice. Licensing and compliance questions belong with qualified Indonesian legal and regulatory advisors. This article covers the engineering side — what has to be built so the regulatory requirements are even achievable. (As of June 2026; rules and deadlines change — verify before deciding.)
The short answer
In Indonesia, two regulators split fintech between them: Bank Indonesia (BI) supervises payment services (e-wallet, e-money, payment gateway, remittance), while OJK (Otoritas Jasa Keuangan) supervises non-payment fintech (P2P lending, securities crowdfunding, and similar). Which one governs you decides your obligations — and your architecture. On top of that sit data-localization rules and UU PDP. A fintech developer worth hiring builds KYC/AML, an audit trail, data residency and licensing-aware foundations in from the start, so your product can pass scrutiny without being rebuilt. The wrong partner ships something that works — until it's examined.
Who regulates what — and why it changes your build
This split is the first thing a competent partner clarifies, because it determines everything downstream:
- Bank Indonesia (BI) — payment fintech: e-wallets, e-money, payment gateways, remittance. BI Regulation 10/2025 tightened the regime with enhanced governance, comprehensive risk management, a required Payment System Business Plan, and end-to-end supervision from licensing to exit. As of 2026, hundreds of payment service providers are licensed under BI.
- OJK — non-payment fintech: P2P lending (pinjaman online), securities crowdfunding, and related services. OJK's July 2025 Circular Letter (No. 19/SEOJK.06/2025) introduced new operational requirements for P2P platforms, with compliance required by 1 January 2026 — including a cap limiting non-professional lenders to 20% of a platform's total outstanding funding.
The umbrella law over all of this is Law No. 4 of 2023 (the P2SK Law) on strengthening the financial sector. And foreign fintech businesses offering P2P lending, securities crowdfunding or BNPL are statutorily required to obtain the relevant OJK (or BI, for payments) license to serve Indonesian customers. The regulatory category isn't a label — it dictates licensing, reporting and how your system has to behave.
What a fintech developer in Indonesia must handle
These aren't nice-to-haves. They decide whether your product survives a partner's due diligence or a regulator's question.
| Requirement | Why it's critical | What has to be built |
|---|---|---|
| Licensing-aware architecture | BI vs OJK category dictates obligations | A system that fits the regulated activity, not one retrofitted later |
| KYC/AML | Mandatory customer due diligence | Onboarding with identity verification, risk scoring, ongoing monitoring |
| Data localization (GR 71 / sectoral) | Financial-sector data may have to stay in Indonesia | Indonesia-region hosting, documented data flows |
| Audit trail | Regulators and partners want "who, what, when" | Immutable logs of sensitive actions |
| Payments (QRIS / e-money rails) | Indonesian users expect local payment | Integration with QRIS and local providers, reliable state handling |
| App registration (Komdigi) | Fintech apps must register with the Ministry | Compliance step tracked, not discovered late |
Whether these are cheap (designed in) or expensive (bolted on after a rejection) is decided by the architecture, not the feature list.
Data localization: where your data has to live
This is the rule that quietly dictates infrastructure. Under Government Regulation 71/2019 (GR 71), Indonesia splits operators into public and private Electronic System Operators (ESOs):
- Public ESOs must process and store personal data in Indonesia.
- Private ESOs may process and store data offshore — provided they maintain effective legal enforcement and give Indonesian authorities access on valid request.
- But if a private ESO is bound by sectoral regulation — and financial services is exactly that — it may be required to keep personal data in Indonesia only.
In practice, a regulated fintech should assume Indonesian data residency is likely and design for it, rather than discover it after launch. A new implementing regulation promulgated in March 2025 tightened this further, with public ESPs required to fully comply by March 2026 or face progressive sanctions up to blacklisting and delisting. Personal data overall is governed by UU PDP (Law 27/2022) alongside the EIT Law and GR 71 — so consent, retention and per-user data isolation belong in the design from day one. The wider localization, payments and PSE-registration picture for foreign founders is in Building Software for the Indonesian Market.
What you build versus what you document
A seasoned fintech partner separates the two cleanly:
- What you build: identity verification in onboarding, risk scoring, audit trail, Indonesia-region data handling, QRIS/payment integration, a role and permission model, monitoring that can surface incidents.
- What you document: data flows, where data is stored, third-party providers, recovery procedures, responsibilities — the evidence a partner or regulator asks for.
A build with no documentation fails review; documentation with no technical foundation is just a promise.
When you need a fintech specialist — and when you don't
Not every fintech idea needs a heavily specialized regulatory-engineering partner. An honest split:
Specialist makes sense when: you're doing a licensable activity (payments/e-money, P2P lending, crowdfunding), you handle real customer funds or sensitive financial data, or a bank/regulator partner is asking for concrete evidence.
Generalist plus a compliance advisor is often enough when: you're in early validation, not yet doing a regulated activity, or operating behind a licensed partner (Banking-as-a-Service / embedded finance), or working in a regulatory sandbox. Here the key is that the architecture doesn't preclude later regulation — not that everything is finished on day one.
The most expensive mistake is confusing the two: launching a regulated product on a "fast and cheap" architecture, then rebuilding it after the first serious review.
What to look for in the partner
Beyond fintech familiarity, the same engineering fundamentals make a product examinable: security-by-design rather than security bolted on, a dependable audit trail, Indonesia-region data residency with documented flows, code ownership from day one (the system is yours, not the vendor's), and a clean handover with documentation. These are what decide whether a partner's or regulator's question is answered in hours or in weeks. It's the same backbone we bring to custom platforms and backend engineering across other regulated and operations-heavy products.
Citable facts
- In Indonesia, Bank Indonesia regulates payment fintech (e-wallet, e-money, payment gateway, remittance); OJK regulates non-payment fintech (P2P lending, securities crowdfunding). Umbrella law: Law No. 4 of 2023 (P2SK).
- OJK's 2025 Circular Letter (No. 19/SEOJK.06/2025) set new P2P operational rules, effective 1 January 2026, including a 20% cap on non-professional lender funding.
- Under GR 71/2019, public ESOs must store personal data in Indonesia; private ESOs in regulated sectors (incl. financial services) may also be required to localize. Public ESPs must comply with the March 2025 implementing rules by March 2026.
- Personal data is governed by UU PDP (Law 27/2022); fintech apps must register with the Ministry of Communication and Digital (Komdigi); foreign P2P/crowdfunding/BNPL providers need OJK/BI licensing to serve Indonesian customers.
(As of June 2026. Not legal or regulatory advice — rules and deadlines change; verify with qualified Indonesian legal/compliance advisors before deciding.)
Building a fintech product for the Indonesian market and need an engineering partner who designs with OJK, Bank Indonesia and UU PDP in mind? H-Studio is an architecture-first software studio working with founders in Bali and across Indonesia. We build the technical foundations — KYC/AML-ready onboarding, audit trail, Indonesia-region data handling, QRIS/payment integration — so your product can stand up to scrutiny, with code ownership from day one. The regulatory assessment stays with your legal/compliance advisors; we provide the engineering. Tell us about your fintech project.
FAQ
Who regulates fintech in Indonesia — OJK or Bank Indonesia? Both, by category. Bank Indonesia supervises payment fintech (e-wallet, e-money, payment gateway, remittance); OJK supervises non-payment fintech (P2P lending, securities crowdfunding). Which one governs you determines your licensing and obligations.
Does my fintech data have to be stored in Indonesia? Possibly. Under GR 71, public electronic system operators must localize personal data, and private operators in regulated sectors like financial services may also be required to. A regulated fintech should design for Indonesian data residency rather than assume offshore is fine. Confirm with a legal advisor.
Do foreign founders need an Indonesian license for a fintech product? Foreign businesses offering P2P lending, securities crowdfunding or BNPL must obtain the relevant OJK (or BI, for payments) license to serve Indonesian customers. Whether your specific product is licensable is a legal question — but the architecture should anticipate it.
Can I build an MVP before getting licensed? Often yes, in early validation or behind a licensed partner (BaaS) or in a sandbox. The key from an engineering standpoint is that the architecture doesn't preclude later regulation — KYC, audit trail and data residency should be designed in, not retrofitted. (More on scoping a first build in our guide to building an MVP.)
Reviewed by the H-Studio Indonesia editorial team.
Important disclaimer. This article is general engineering and product guidance for founders evaluating how to build fintech software in Indonesia, not legal, tax, regulatory or licensing advice. Indonesia's regulatory framework — including the P2SK Law (Law No. 4 of 2023), Bank Indonesia Regulation 10/2025, OJK Circular Letter No. 19/SEOJK.06/2025, Government Regulation 71/2019 and its March 2025 implementing rules, UU PDP (Law No. 27/2022), and Komdigi app/PSE registration — applies independently, is hedged and dated here (as of June 2026), and is changing through 2026 and beyond. Licensing categories, deadlines, localization obligations and supervisory expectations differ by product and change without notice. Confirm the current position, and whether your specific product is licensable, with qualified Indonesian legal and compliance advisors before building or launching.
