OJK Compliance for Indonesian PSPs: FMS, PJP Licensing and AML

Fintech payment service providers in Indonesia operate under a licensing framework that becomes significantly stricter the moment they seek to expand their payment scope. Bank Indonesia issues PJP licenses across three categories, and moving from category 3 to category 2 triggers mandatory fraud management system, eKYC and AML requirements that must be evidenced, not simply declared.

For compliance officers and product leads at Indonesian payment platforms, understanding precisely what OJK and Bank Indonesia require at each stage is what separates a successful license upgrade from a delayed one.

What Is a PJP License and Why Does the Category Matter?

A PJP license is what Bank Indonesia issues to payment service providers operating in Indonesia. There are three categories, and the higher you go, the more you are allowed to do and the stricter the compliance requirements become.

Category 3 is the entry level. Limited payment scope, lighter infrastructure requirements. Category 2 is where most growing platforms want to be: it covers payment gateway functions and a broader range of transaction types. Category 1 is for e-wallet operators like GoPay or Dana.

The category matters because the compliance bar is different across the three. A manual KYC process and a basic in-house fraud tool might be acceptable at category 3.

At category 2, Bank Indonesia expects a production-grade FMS, automated eKYC and operational AML screening. The same controls that got you licensed at category 3 will not get you approved at category 2.

What the PJP Category 2 Upgrade Actually Requires

Bank Indonesia does not take your word for it. Category 2 applicants must demonstrate that their FMS is working in a live or near-live environment, submit documentation and demonstrate that eKYC is automated and that AML screening runs at onboarding. A policy document describing what you plan to build does not pass.

This matters for timing. The FMS must be in place before you file the application, not after you are approved. Platforms that treat it as a post-approval project find out at the worst possible moment that BI will not move forward without it.

For platforms that built fraud controls in-house, the upgrade usually exposes the same gap. What you built to satisfy your own internal requirements and what BI expects to see as a licensed operator are rarely the same thing. The documentation alone covers system architecture, rule logic and governance records and typically exceeds what an in-house build can produce.

OJK FMS Rules: What Examiners Actually Check

OJK does not tell you which vendor to use. It tells you what your FMS must do, and it expects you to show it doing those things — not describe it in a document that has never been tested.

The required rule types cover velocity checks, transaction pattern monitoring and device-level detection. Those are the baseline. OJK expects you to have built on top of them based on your own risk profile. A system running only on default rules with no customization is the first thing an examiner will push back on.

The second thing they will ask is how you maintain your rules. Fraud patterns change. If your rule set looks the same as it did 18 months ago, that is a problem. OJK wants to see a governance process — someone owns the rules, reviews them regularly and can explain why each one exists.

PPATK and KPK: Why Global AML Lists Are Not Enough

PPATK is Indonesia’s financial intelligence unit. It runs a watchlist of individuals and businesses flagged for money laundering and other financial crime under Indonesian law. KPK is the country’s anti-corruption commission and keeps its own list of people under investigation or convicted of corruption. Both are maintained locally, and both are ones OJK expects you to screen against.

The problem with relying only on global lists like OFAC or the UN consolidated list is that they do not consistently include Indonesian-specific entries. Someone flagged by PPATK may not appear on any international database. If your screening tool only covers global lists, you will miss them, and OJK will find the gap.

For platforms screening both senders and beneficiaries at the transaction level, this is a vendor question you need to ask upfront. Does the FMS include PPATK and KPK data? How often is it updated? Can the vendor show you that update frequency in writing? If not, that is a compliance gap sitting in your stack right now.

How STR and SAR Reporting Connects to Your FMS

A Suspicious Transaction Report, or STR, is filed with PPATK when a PSP identifies a transaction that may indicate money laundering or other financial crime. A Suspicious Activity Report, or SAR, covers broader patterns of suspicious behavior that may not involve a single flagged transaction.

Both are regulatory obligations, and OJK expects both to originate from the FMS case management workflow.

Most PSPs buy an FMS to catch fraud. OJK cares about that, but it also cares about the paper trail. A system that flags suspicious activity but requires analysts to rebuild the case narrative in a separate document creates a gap that examiners will find.

The standard OJK expects is straightforward: the FMS generates an alert, the analyst documents their findings inside the case management module, and the system produces a report that can go to PPATK with minimal editing. At high transaction volumes, the reporting workflow cannot be manual. The time cost alone makes it unsustainable.

Account Takeover: The Primary Fraud Risk for Indonesian PSPs

Account takeover exploits the gap between device-level security tools and fraud detection systems, which is why it causes the most direct financial loss for Indonesian payment platforms. Many PSPs use a dedicated security tool to detect rooted devices or emulators and force-close the mobile app when a threat is detected.

That action, however, happens independently of any fraud scoring.

Integrating device intelligence into the fraud detection layer means the session data that triggers a security response also contributes to the transaction risk score. That connection gives fraud analysts richer context when reviewing flagged activity and reduces the volume of manual reviews that result in no action.

The authentication layer is where this integration matters most. Monitoring login events, account edits and transaction initiation as a connected sequence, rather than as isolated checks, allows a PSP to detect patterns that no single event would surface on its own.

A credential change followed immediately by a high-value transfer from an unfamiliar device is one example of a pattern that requires cross-event visibility to catch reliably.

Data Residency: The Bank Indonesia Requirement Most PSPs Miss

Bank Indonesia requires that customer data be stored and processed inside Indonesia. Not in Singapore. Not in a regional hub. In Indonesia. That requirement applies to your FMS vendor just as much as it applies to your own infrastructure.

A vendor with a strong product but no Indonesian data center does not satisfy this requirement. It does not matter how good their compliance documentation is elsewhere. If Indonesian customer data is being processed outside the country, you are non-compliant.

This is the question most PSPs ask too late in the procurement process. By the time legal is reviewing contracts, months of evaluation work may have been done on a vendor that cannot actually operate in this market. Ask about the Indonesian data center in the first call, not the last.

How to Meet OJK Compliance in Phases

Not every PSP needs everything live before filing a category 2 application. OJK’s framework is built around documented controls and evidence of operational effectiveness, which means a phased approach works — provided each phase is genuinely running, not just integrated on paper.

Start with AML screening and core transaction rules. That covers the most visible OJK requirements and gives BI the documented evidence it expects in the application. Device intelligence and behavioral checks can follow as the platform scales.

The constraint is that documentation must be provided at every stage. Each phase needs a written risk policy, board-level sign-off and an audit trail. If it is not written down, it did not happen as far as OJK is concerned. A rollout that exists only in the codebase, with no governance record to back it, will not hold up under scrutiny.

OJK FMS Vendor Checklist

Most FMS vendors will tell you they are compliant with Indonesian regulations. Few can show you the PPATK integration, the Indonesian data center confirmation and an OJK rule mapping document. Those three things are the difference between a vendor that fits this market and one that does not.

PPATK and KPK integration is the first filter. If a vendor cannot confirm these lists are included, kept current and documented, the conversation ends there. Data residency is the second. A vendor without an active Indonesian data center does not satisfy BI’s requirement, regardless of how good the product is.

OJK rule mapping matters more than general compliance claims. Ask the vendor to demonstrate how their configurable rules align with OJK’s published requirements. That document is what you will hand to examiners.

Finally, STR and SAR report generation must be a native capability inside the case management module, not a future roadmap item. If your analysts are drafting reports in Word and copying data across from the FMS, that workflow will not scale, and it will not satisfy OJK.

FAQ

Regulatory & Market Context (the “Why Now”)

• POJK 12/2024 — OJK’s sweeping anti-fraud regulation requires AI-driven analytics to detect fraud rings and mule networks, strengthened internal controls, and reporting of significant fraud incidents to OJK within three business days, with sanctions for non-compliance.