Indonesia's OJK-licensed digital lenders and neobanks spent considerable energy over the past few years building customer onboarding flows that collect GoPay and OVO transaction history as part of their AML/KYC identity verification process. The data gets checked against sanction lists and used to verify account activity. Then it sits in a compliance database, never connected to the credit decisioning stack.
We encountered this pattern repeatedly when scoping potential integrations with Indonesian digital lenders in late 2025. The gap isn't a technical problem. The data exists, it's already been consented to by the borrower, and the infrastructure to extract and process it is available. The gap is organizational: the compliance team collected it, the credit team doesn't have a connector to it, and nobody has had enough incentive to build the bridge.
That's a significant opportunity cost. Indonesia's iDEB (Informasi Debitur) bureau has reasonable coverage of formal credit history among salaried workers with bank accounts. For the urban gig worker, the informal trader, and the underemployed graduate picking up platform work while job hunting, iDEB is often blank or sparse. The GoPay and OVO transaction history those same borrowers generated over 24 months during the onboarding flow tells a considerably richer story.
What Indonesian E-Wallet Data Contains
GoPay and OVO are both deeply integrated into daily transaction behavior for Indonesian urban consumers in ways that go beyond what Western mobile payments capture. GoPay is embedded in the Gojek super-app ecosystem: ride payments, food delivery, grocery runs, and bill settlements all flow through it. OVO sits inside Grab and has a significant merchant QR acceptance footprint. Both have peer-to-peer transfer functions used for informal obligations, rent payments, and small business transactions.
For a borrower in Jakarta or Surabaya who uses either wallet as their primary payment instrument, a 24-month transaction history gives you: income inflow patterns (salary deposits, gig platform payouts, informal transfers), recurring expenditure commitments (regular bill payments, subscription services, regular merchant payments that resemble rent or education fees), seasonal spending shifts, and behavioral patterns around financial buffer management.
The OJK's POJK No. 10/POJK.05/2022 on peer lending platforms, updated in later revisions, permits the use of alternative data in credit assessments provided borrower consent is obtained and the data use is disclosed in product documentation. Neobanks operating under their own OJK fintech licenses have similar latitude. The regulatory basis for using this data in scoring exists. The constraint is practical, not legal.
The AML-to-Credit Bridge Problem
When we look at why this data doesn't flow from compliance to credit, the root cause is almost always a combination of data architecture and internal incentive structure.
On the architecture side: AML transaction monitoring systems are typically built on different infrastructure from credit origination systems. One operates in batch mode for regulatory reporting; the other needs low-latency lookups at origination. The raw transaction records extracted for AML purposes are often stored in a compliance-specific data lake or reporting database that the credit team's data pipelines don't reach. Building the bridge requires cross-team cooperation and someone to own the integration work, which tends to fall through the cracks in lean engineering teams.
On incentives: the compliance team has no upside from enabling the credit team's use of the data. Their job is regulatory adherence, not portfolio optimization. The credit team may not know the data was collected or may have only a vague understanding of what's in it. Risk management teams sometimes resist using data that wasn't originally collected for credit purposes, on grounds of model interpretability and regulatory examination risk, even when the data use is permitted.
We're not suggesting this is an easy organizational problem to solve. But the lenders who crack it have a meaningful underwriting advantage in a market where iDEB coverage leaves significant portions of their addressable borrower population unscored or underscored.
A Practical Assessment of the Signal Quality
E-wallet data isn't a magic fix for Indonesia's credit gap, and we want to be specific about where the signal is strong and where it attenuates.
The strongest signals are in behavioral consistency features. Income inflow regularity, ratio stability between inflows and outflows, and minimum balance behavior all translate well from the Vietnam and Philippines markets where we've run production models. The underlying behavioral economics of why these features predict repayment are market-agnostic. What changes is the calibration: Indonesian informal income patterns have different seasonal cycles, different platform payout frequencies (Gojek pays weekly or daily depending on driver tier), and different peer-transfer norms.
The weaker signals in the Indonesian context are merchant category inferences. In markets with more standardized merchant category codes, spending patterns on specific categories (education payments, grocery regularity, entertainment spending) can encode useful socioeconomic context. GoPay and OVO's merchant categorization is less standardized than in more mature payment markets, which means category-level features add noise rather than signal unless you do substantial post-processing to clean up the category labels.
Geographic signals present a different complexity. Indonesian urban-to-rural financial behavior varies substantially, and a borrower who transacts primarily in a tier-2 or tier-3 city looks different from one in Jakarta even at the same income level. Building geography-stratified models, or at minimum including geographic tier as a feature, matters more in Indonesia than in more economically homogeneous markets.
What Good Integration Architecture Looks Like
For a neobank or digital lender that has collected this data and wants to start using it for credit scoring, the practical integration path involves a few components that are worth building correctly from the start.
A consent and disclosure layer needs to be explicit that transaction data is used in credit assessment, separate from its use in identity verification. Many current onboarding flows bundle both uses under a single consent language that's technically sufficient but poorly communicates the credit use to borrowers. Regulators in several markets have started scrutinizing this, and building explicit consent language now avoids a retrofit later.
A feature extraction service that operates independently of the compliance data warehouse gives the credit system a clean interface without requiring the compliance team to restructure their infrastructure. The feature service ingests raw transaction exports on a scheduled basis, computes the scoring features (not the raw transactions), and stores only the features in the credit system's data store. This architecture respects data minimization principles and keeps the compliance system intact.
Finally, the model itself needs to be calibrated specifically for the Indonesian market's behavioral patterns, not ported from Vietnam or Philippines models. Feature distributions differ enough that a model trained on one market's data will produce miscalibrated scores in another, even using nominally identical features. This isn't a minor tuning issue; it's a systematic shift in the underlying feature distributions that affects Gini and PSI materially.
The Timing Question
The opportunity window for building this advantage isn't indefinite. As iDEB coverage expands with more financial products flowing through OJK-licensed channels, the bureau data gap will narrow. Lenders who build cash-flow underwriting infrastructure while the gap is still large will have both a cost advantage (lower reliance on expensive bureau lookups for a segment where the bureau returns sparse data anyway) and a model quality advantage built from proprietary behavioral data that competitors won't have access to.
The lenders most likely to move first are those who have already built internal data science teams capable of the feature engineering work. The ones most at risk of being late are those still running rule-based origination with external bureau scores as the primary input, without the in-house capability to process transactional data. That gap in analytical capability is a harder problem than the data availability gap, and it's the one worth prioritizing.
