Every Indonesian digital bank leadership team is having the same conversation right now. Someone has returned from a conference, or read a competitor announcement, or sat through a vendor demo, and the question is now on the table: what is our AI strategy?
But then the conversation stalls, usually for predictable reasons. Perhaps the use cases seem obvious in the abstract but murky in practice, or the data situation is complicated, the engineering team has a backlog, and maybe no one wants to be the person who championed an AI project that failed publicly.
The result is that many Indonesian digital banks are spending 2026 planning to do AI rather than actually doing it. Which is a shame, given when applied correctly AI can do a lot of good; it’s already contributed to the financial enclosure rate in Indonesia rising from 49% in 2014 to 83% in 2024.
If this is the situation you’ve found yourself in as a senior technical leader at an Indonesian bank or lender, then read on. This article is a practical roadmap for going from that conversation to a live AI pilot in 90 days. It is written for the leadership teams who need to move from intention to execution without exposing the institution to unnecessary risk.
Why Indonesian digital banks are well-positioned for AI adoption
Indonesia’s digital-first banking market has structural characteristics that make AI both more valuable and more complex than in other markets.
On the opportunity side, the case is strong. Indonesia has over 280 million people, smartphone penetration that has outpaced traditional banking infrastructure with internet penetration hitting 79%, and a credit-underserved middle market that digital lenders are actively trying to reach. Customers communicate across multiple languages and dialects and fraud patterns shift faster than manual rules can follow. These are exactly the conditions where AI adds the most value: building alternative credit assessments from non-traditional data, operating customer support at language scale, and detecting fraud patterns that rules-based systems miss.
On the complexity side, three factors are specific to Indonesia. First, OJK’s evolving AI governance framework means that deploying AI in credit decisions requires explainability standards that many off-the-shelf models do not meet out of the box. Second, data fragmentation is severe: customer data sits across origination systems, core banking, digital channels, and third-party providers, often with inconsistent formatting, incomplete records, and weak linkage between systems. Third, Indonesia’s market is genuinely heterogeneous; a credit model that performs well in Jakarta may perform poorly in East Java or Sulawesi, because income patterns, transaction behaviour, and credit culture differ by region.
None of these factors prevent AI deployment, but they do shape which use cases to start with and how to structure a pilot that generates real learnings rather than just a proof of concept.
The most common mistake: starting with the wrong use case
Most AI pilots in Indonesian digital-first banking start with credit scoring. This is understandable as the upside is significant and vendors are eager to sell. It is also the hardest place to start.
Credit scoring AI requires clean, labelled historical data going back at least two to three loan cycles. It requires explainability documentation that satisfies OJK’s consumer protection requirements and it requires model monitoring infrastructure to detect drift before it degrades portfolio quality. But because it touches credit decisions directly, a failure is not just a technical problem, it’s a regulatory event.
Starting there means 90 days is not enough time. You will spend it on data preparation and never reach a live pilot.
The smarter approach is to start with a use case that has four properties: it generates real business value, it uses data you already have in reliable form, it has a short feedback loop so you learn quickly, and it carries lower regulatory sensitivity so you can iterate without compliance review slowing every cycle.
Three AI pilots you can run in 90 days
Instead, these three use cases meet these criteria for most Indonesian digital-first banks and lenders right now.
Collections prioritisation
Many banks and lenders in Indonesia are managing collections manually or with simple rule-based segmentation such as days past due thresholds, product type, and outstanding balance. This works at low volume but breaks down as the portfolio grows.
An AI model that predicts which customers are most likely to cure with intervention and which customers require escalation versus a self-service payment reminder can significantly improve collections efficiency without adding headcount. The data requirements are modest, they include things like transaction history, repayment behaviour, communication response rates, and basic demographic information that you already hold and the feedback loop is fast: you know within 30 days whether an intervention strategy is working.
OJK sensitivity is lower because you are not changing credit decisions or customer terms, you are changing internal workflow prioritisation. This means the pilot can run in parallel with existing processes, making rollback straightforward if results are not as expected.
A realistic 90-day outcome: a model in production covering your early-stage collections queue, with measurable improvements.
Customer support automation in Bahasa Indonesia
Customer support is expensive, scales linearly with customer volume, and in Indonesia is complicated by the expectation of Bahasa Indonesia communication plus regional dialect sensitivity. Many banks and lenders are handling this with a combination of FAQs, human agents, and basic scripted chatbots that customers find frustrating.
Some large language models can now handle conversational Bahasa Indonesia at a quality level that makes automated support genuinely useful rather than just deflecting easy queries. A well-scoped pilot could handle a meaningful share of incoming queries without escalation to a person.
The data requirements are simple: your existing support ticket history, your product FAQs, and your customer account data via API. OJK sensitivity is moderate here and you’ll need to disclose that customers are interacting with AI and provide a clean escalation path to real agents, but both are fairly straightforward to implement.
A realistic 90-day outcome: automated handling of your top five query types, a measurable reduction in agent volume for those categories, and a clear picture of where the model fails so that you can decide whether to extend scope.
Transaction anomaly detection for fraud
A transaction anomaly detection model should not replace your existing fraud rules, instead it should run alongside them and flag any unusual patterns that your current rules miss. The data you need is transaction history by customer, which you likely already have. The model can be trained on historical fraud cases you have already identified and resolved.
OJK sensitivity would generally be lower because you are adding a protective layer, not changing customer-facing decisions. Model outputs are reviewed by your fraud operations team before any customer action is taken, which maintains oversight in the decision loop.
A realistic 90-day outcome: a model generating anomaly scores on live transactions, reviewed by operations, with documented catch rate versus your existing rules baseline.
The infrastructure question you cannot avoid
Every AI pilot in a digital bank eventually surfaces the same constraint: the data the model needs is either inaccessible, inconsistent, or too slow to retrieve in the format required.
This is a core banking problem, not an AI problem. Models are only as good as the data they run on. If your core banking system cannot provide clean, real-time transaction data via APIs, your fraud detection model will always be working from stale inputs. If customer records are split across systems with no reliable customer identifier linking them, your collections model cannot build a complete behavioural profile.
Indonesian digital-first banks and lenders on modern, API-first cores can move through a 90-day roadmap with data availability confirmed in days, rather than weeks. On the other hand, banks on legacy systems will end up spending the first 30 days, sometimes the entire 90, negotiating data extracts from systems that were not designed to provide them.
This does not mean AI is impossible without a modern core, but it does mean the 90-day timeline compresses the faster your data infrastructure can support it. If your Day 1 data audit reveals that your core cannot provide the data you need in a usable format, the honest answer is that your 90-day AI pilot is actually a 90-day data infrastructure project with an AI pilot attached.
What a successful pilot enables
A live AI pilot that produces measurable results in 90 days does three things beyond the immediate business outcome.
It builds internal capability
The team that ran the pilot now understands how to scope AI use cases, structure data requirements, manage OJK implications, and measure model performance. This knowledge is more valuable than the model itself, because it makes the next pilot faster and cheaper.
It generates board confidence
Indonesian digital-first bank boards are not uniformly sceptical of AI, but they are usually appropriately cautious about uncontrolled experiments that create regulatory or operational risk. A 90-day pilot with a defined scope, clear governance, and published results is exactly the kind of evidence that earns approval for the next, more ambitious use case.
It identifies the infrastructure gaps that limit scaling
No pilot runs perfectly, but the failure modes tell you what to fix before you scale. This is far less expensive to discover at pilot scale than at production scale.
Ready to go from AI idea to live pilot?
Oradian works with digital banks and lenders across Southeast Asia and Africa building AI-ready infrastructure through a core banking foundation, data architecture, and API layer that makes 90-day pilots possible rather than theoretical.
If you are an Indonesian bank or lender ready to move from conversation to execution, drop vanda.jirasek@oradian.com an email to see what a 90-day roadmap could look like given your current infrastructure.
