A QRIS compliance lead is a manager at an Indonesian payment provider who needs to investigate possible gambling-payment misuse but must distinguish suspicious activity from legitimate merchants with similar transaction patterns.
The Problem
A snack seller receives repeated payments of the same amount after the shop has supposedly closed. Is the business taking genuine late orders, using an outdated registration profile, or lending its payment account to someone else?
That is the kind of question behind Bank Indonesia’s push for closer QRIS merchant oversight. QRIS is Indonesia’s national QR payment standard. In October 2026, Fintech News Indonesia reported the central bank’s call for stronger merchant verification, continuing monitoring and action on suspicious payments. The report includes a closed snack shop receiving repeated midnight payments as an example of activity needing attention. [1]
An unusual pattern is a reason to investigate, not proof of gambling. Fixed prices can produce identical amounts. Legitimate businesses can trade late. Payments that look ordinary can also conceal misuse.
A compliance team therefore needs to connect what it sees in the payment stream with other evidence about the business. Three questions may matter: does the activity fit the merchant’s current business, has a relevant identifier appeared in a reliable flagged record, and does the pattern of payer activity warrant investigation?
If the information needed to answer those questions is unavailable, unreliable or disconnected from review, an analyst may have to reconstruct the case manually—or reach a decision without important context. That can consume capacity and leave genuine concerns unresolved. This is the operational bottleneck these ideas would test. The reporting establishes the oversight concern; it does not establish which information gaps exist at a particular provider.
What Could Work?
Three distinct ideas could help a payment provider assemble better grounds for review. Their likely buyers and demand remain unverified.
Context Review: link unusual transactions to dated merchant information, so the reviewer can assess whether the activity fits the business. A provider’s compliance team might pay an integration team to reduce case-preparation work while preserving decision quality.
Flagged-List Review: add a check against a lawfully accessible, relevant flagged list during merchant onboarding. A provider’s risk team might pay a data-integration service to identify possible links earlier and document how each match was assessed.
Payer-Pattern Review: where suitable payer identifiers are actually available and may lawfully be used, look for merchant-level patterns that amount-and-time rules miss. A provider’s fraud team might pay an analytics team for additional useful leads within its existing review capacity.
None would automatically prove gambling, reject a merchant or delay settlement. Each would feed the provider’s authorised review process.
How It Could Work
Context Review
A payments engineer first checks how transaction records link to merchant profiles and the existing case queue. For a merchant receiving repeated late-night payments, the case would show timestamps and amounts alongside the business category, the source and date of trading-hours information, and any subsequent verification.
Missing or old hours would remain unknown. They would not become evidence that the shop was closed. The case would explain the mismatch, show possible legitimate explanations and identify what the reviewer still needs to establish.
The reviewer would request clarification, escalate or close the case under existing procedures. Evidence, rule versions and later profile corrections would remain traceable. The inventive move is to make review priority depend on the relationship between transaction behaviour and business context. A profile used at registration gains a continuing job.
Flagged-List Review
Before building a matching engine, the team would establish whether the provider can lawfully access a relevant list and whether its identifiers match anything the provider collects. A news report that accounts were flagged does not provide such a list.
If access and overlap are confirmed, onboarding would include a documented check against a dated list version. A possible match would go to a trained reviewer, who would assess the identifier, source, reason and status of the flag. A matching name alone would not justify rejection; an exact identifier can also need investigation where identities or accounts have been misused.
The record would distinguish a confirmed match, an uncertain match and no match. No match would mean only that this check found nothing. The inventive move is to give the existing onboarding step another task: bringing relevant prior flags into the review before the relationship begins.
Payer-Pattern Review
This idea needs a different input. The provider must confirm that it holds a stable payer token with a documented meaning and coverage, and that the proposed use is permitted. A transaction ID or timestamp cannot reveal whether two payments came from the same payer.
If that check succeeds, an analyst could calculate the share of a merchant’s transactions associated with its most frequent payer tokens, alongside repeat-payment frequency. Those patterns would be compared with appropriate merchant groups and the provider’s existing rules.
An unusual concentration would generate an explanation for human review. A token might represent an account or wallet rather than a unique person; shared wallets and corporate purchases could produce legitimate concentration. The inventive move is to examine the distribution of payments across payer tokens, adding a different perspective to the amount of each payment.
Why It Might Work
Context Review could reduce the effort of finding information the provider already holds. Its first benefit would be a better-supported disposition with less reconstruction, rather than a claim to detect a new class of crime.
Flagged-List Review could bring relevant prior information into a decision earlier. Its advantage depends on lawful access, meaningful identifiers and flags whose status a reviewer can interpret. It cannot identify merchants absent from the list.
Payer-Pattern Review could add leads where transaction amounts and timing alone reveal little. Whether its signals distinguish misuse from legitimate activity remains an empirical question.
There is reason to investigate these routes, but no empty field to claim. PPATK has described smaller, frequent payments and misuse of merchant identities, while also noting improved detection. [2] Bank Indonesia’s regulatory summary includes ongoing monitoring, and its research catalogue includes a working paper on online-gambling transaction patterns. [3] [4] Each pilot should compare the idea with tools and procedures the partner already uses.
What Could Get in the Way?
For Context Review, stale profiles and unreliable merchant links could make a convincing explanation misleading. If analysts already receive useful context, another integration may add little.
For Flagged-List Review, the necessary list may be unavailable, restricted, outdated or missing identifiers that overlap with onboarding records. A list of suspected accounts is not automatically a list of confirmed gambling merchants. If access or matching fails, the proposed screening mechanism cannot operate.
For Payer-Pattern Review, usable tokens may not exist in the provider’s records or may cover only some transactions. Concentration may reflect legitimate shared accounts, while misuse distributed across many payers may look ordinary. More alerts could simply create more work.
All three require appropriate data access, security and decision authority. Indonesia’s Personal Data Protection Law is relevant where records identify individuals. Replacing names with codes does not by itself establish lawful use. [5] An internal case record would document work; it would not certify compliance or replace required reporting.
What Would It Take to Find Out?
Context Review
Observe current practice, then compare existing case files with context-enriched files in a matched exercise of at least 30 historical review episodes. Allow two weeks for preparation and four weeks of shadow observation. Vary which reviewers see each format and count preparation, review and follow-up work.
A provisional continuation target is at least 20% less total handling time across the entire preselected matched case set, with no reference case requiring escalation incorrectly cleared and no increase in unresolved cases. Every assigned case must be completed and independently assessed before that timing target can be declared met. These are proposed criteria, not measured results or a regulatory standard. Faster decisions would not count as success if another employee merely inherited the work.
Flagged-List Review
Start with an access and identifier check. If it passes, use a frozen set of onboarding records and an authorised, dated list to compare assisted matching with the existing process over four weeks. Review every proposed match and a sample of non-matches independently.
Measure match correctness, unresolved matches and staff time. False matches or missed known identifier links would count against the method. If only a current list is available, the exercise can assess present matching; it cannot show what screening would have prevented at an earlier onboarding date.
Payer-Pattern Review
Begin with a data and privacy check. If it passes, use an earlier historical period to develop the features and a separate later period to compare them with existing rules. Then run four weeks in shadow mode without changing live decisions.
At the same review capacity, does the new approach contribute additional independently supported escalations, or mainly duplicate alerts and legitimate unusual trading? If usable outcome evidence is absent, the pilot can measure feasibility and workload but cannot claim better detection. Unreliable token coverage, no incremental useful leads or substantially more unresolved work would count against proceeding.
Who Could Make It Work?
One provider’s risk team and qualified privacy and regulatory counsel would be common partners. No named institution has agreed to participate.
Context Review needs a payments engineer and an experienced compliance analyst. Flagged-List Review needs a data engineer, an authorised list custodian and reviewers able to assess identity matches. Payer-Pattern Review needs a data scientist and a provider data specialist who can establish what its payer tokens represent.
If you review QRIS merchant activity, which missing connection causes the most work today: current business context, relevant prior flags or a useful view of payer behaviour?
Research Notes
These are three untested hypotheses. Evidence, demand and success for one do not establish those of the others.
Sources and provenance
[1] Fintech News Indonesia — “Indonesia Balances QRIS Cross-Border Expansion with Merchant Oversight,” 22 October 2026. Read the original selected news story. Retrieved and full page read on 22 October 2026; text retained. This secondary report attributes its merchant-oversight reporting to ANTARA. It supports the attributed call for closer vetting, continuing monitoring and follow-up on unusual payment patterns. The article’s snack-shop example is an indicator requiring investigation, not an adjudicated gambling case. DetikFinance’s report of the same remarks, 21 October 2026, was also read in full and retained. These reports do not establish a prescribed anomaly threshold, automatic settlement delay, regulator-approved report template or a tool gap at a selected provider. The reported bank-account figure is not used as a count of confirmed gambling merchants.
[2] PPATK — “Judi Online Membajak Piala Dunia 2026, Deposit Tembus RP 1 Triliun,” release dated 4 August, web publication 5 August 2026. Read the official release. Full release read through web retrieval on 22 October 2026; direct archival retrieval returned an HTTP error. Supports the agency’s account of smaller, frequent payments, merchant/identity misuse and improved detection. Its aggregate findings do not measure prevalence at the pilot provider or validate this proposed mechanism. No national loss or transaction total is presented as a recoverable saving.
[3] Bank Indonesia — PBI 10/2024, anti-money-laundering and related prevention framework, issued 31 December 2024. Read the official regulation summary. Official summary checked on 22 October 2026, including coverage of specified non-bank providers and ongoing due diligence. Subsequent page retrieval was intermittent; direct archival retrieval failed. The summary establishes that monitoring is an existing responsibility, not this idea’s invention. Counsel must check the complete, currently applicable framework and the partner’s actual role. A merchant aggregator is not assumed to have the same licence, access or authority as every payment provider. The article does not prescribe statutory reporting deadlines or claim that an internal record satisfies a regulator.
[4] Bank Indonesia — “Identification of Illegal Transaction Patterns in Payment System Data Using AI/ML: A Case Study on Online Gambling,” working paper WP/14/2025, catalogue entry dated 10 March 2026. Read the publisher’s research entry. Catalogue title, authorship and publication metadata checked on 22 October 2026. The full paper was not read; no model performance, operational deployment or data-field availability is inferred from it. It establishes relevant existing research, not a validated competing product or a result for this pilot.
[5] Law 27/2022 on Personal Data Protection. Read the official BPK database record. Metadata and abstract checked on 22 October 2026; listed as in force. This identifies the relevant framework, not legal clearance for the pilot. Review the processing purpose and basis, roles, minimisation, retention, security, access and any external processing arrangements. Merchant records can identify natural persons. Pseudonymisation is not assumed to remove those obligations.
Shared evidence and decision boundaries
Source checked: oversight and continuing monitoring already exist [1, 3]; PPATK describes both adaptive misuse and improved detection [2]. No source establishes that the three proposed capabilities are absent at a selected company. Compare existing fraud rules, due-diligence reviews, onboarding screening, case-management tools and internal configuration before buying anything new.
Unverified shared problem: a particular team lacks a useful connection between its transaction review and other relevant evidence. Observe cases and interview staff before choosing a pilot. Unknown effectiveness is not proof that a hypothesis is logically broken; missing essential access, however, prevents its proposed pilot from proceeding.
Counsel must establish the partner’s actual regulatory role, processing purpose and basis, permitted data access, retention, security and reporting responsibilities. An aggregator is not assumed to have the same licence or authority as every payment provider. No universal settlement-hold permission, reporting deadline or approved evidence template is inferred from the sources. The prototypes do not suppress existing alerts, contact merchants, submit reports, reject applicants, blacklist businesses or alter payments. Existing authorised operations continue separately. Any later intervention needs its own assessment.
Keep merchant joins, transaction status, time zones, reversals and duplicate records explicit. Limit access to authorised staff. Do not publish identifiable records. The pilots require no public accusation of a merchant and no purchase of suspect-account or identity data from unauthorised sources.
Context Review
Mechanism and decisive uncertainty: attach dated business context to a transaction-review episode so an analyst can reach a supported disposition with less reconstruction. Merchant ID, amount, timestamp and meaningful profile data must actually be present and joinable; availability is unverified. Missing hours remain unknown. An apparent mismatch is not proof of illegal activity. The existing case system is the closest alternative.
Pilot: one authorised provider; two weeks of preparation and four weeks of shadow observation. Select at least 30 historical merchant-review episodes covering categories, legitimate unusual activity, missing context and previously escalated cases. Record selection and exclusions. Freeze the rules and use only information available at the episode’s review time. Later findings can inform independent reference adjudication but must not leak into reviewer inputs or rule tuning.
An independent senior reviewer or panel defines reference dispositions under the partner’s existing procedures before comparing formats: escalation, supported closure or unresolved. A flagged account is not automatically a confirmed gambling case. Vary format assignment across reviewers and matched cases; report learning effects and reviewer differences.
Measures and denominator: total preparation, active review and attributable follow-up minutes across all assigned episodes in each format, divided by the number assigned. Include data cleaning, profile lookups, corrections and specialist input. Report incomplete episodes and elapsed time separately. All assigned episodes remain in completion and quality reporting; unresolved is not benign. Freeze an evaluation set of at least 30 matched episodes before testing. Every assigned episode in that set must be completed and reference-adjudicated before applying the illustrative timing gate; if any remain incomplete or unadjudicable, report feasibility only and do not declare the timing target met.
Provisional continuation gate: at least 20% lower aggregate handling time across the entire frozen matched evaluation set, zero reference-escalation episodes incorrectly cleared and no increase in unresolved dispositions. These are proposed design choices, not validated tolerances. Do not claim savings by abandoning difficult cases. For proposed queue ordering, compare at the same pre-agreed capacity and inspect a documented sample below the cutoff as well as cases above it. A small sample cannot establish a low population error rate or prevented losses.
Buyer and economics: the provider’s compliance team might pay an integration team. Demand is unverified. Recurring sale unit: one provider-month with a specified portfolio, case volume, integrations and support hours. Monthly cost = preparation/update/support hours × fully allocated rates + hosting/security + recurring expert review. Monthly contribution = fee − monthly cost. Quote setup separately and exclude it from recurring cost. Price, hours, rates, context-update burden and clients per worker remain unknown; measure them against configuring the existing case system. No licence penalty or national fraud total is an attributable saving.
Flagged-List Review
Mechanism and decisive uncertainty: compare onboarding identifiers with an authorised, dated source of relevant prior flags and route possible matches to human assessment. The source, legal access, identifier overlap, update process and meaning of each status must be confirmed. The reports in [1] do not establish an accessible feed. Hashing cannot create missing identifier overlap or legal permission. A no-match is not evidence that a merchant is safe. Existing onboarding screening is the closest alternative.
Pilot: first obtain approval from the actual custodian and verify a usable schema. Stop if access or identifier overlap is absent. For a four-week matching exercise, freeze the eligible onboarding population, source list and versions before testing. Document all input rows, rejected rows, duplicates and missing fields. Use current authorised records, or historical versions that were actually available at the relevant onboarding dates; never present a current-list backtest as historical prevention.
Compare assisted matching with the partner’s existing screening on the same inputs and permitted evidence. Review all candidate matches and an independently selected sample of non-matches, with adjudicators blind to which method raised them. Verify identifier links and assess the significance of flags separately. Correctly linking an identifier does not prove gambling or justify rejection.
Measures and denominator: correct identifier matches divided by all proposed matches; missed known links divided by all independently established links in the registered evaluation set; unresolved matches divided by all proposed matches; total preparation/review minutes divided by all assigned records. Report unreviewed non-matches and uncertainty from sampling; do not compute population-wide recall from a handpicked set of flagged records. If independent link evidence is unavailable, report matching feasibility only.
Decision rule: before evaluation, the compliance team sets acceptable match quality, missed-link tolerance and workload against its current procedure. Do not tune these limits after seeing outcomes. Continue only if the registered limits are met and the method offers a useful improvement; stop or redesign for missing access, misleading identity links, excessive unresolved cases or no incremental value. A small matching exercise cannot establish reduced gambling, regulator acceptance or the consequences of automatic rejection.
Buyer and economics: the provider’s risk team might pay a data-integration service for lawful list integration, matching and maintenance. Demand is unverified. Recurring sale unit: one provider-month with a specified source, update frequency and screening volume. Monthly cost = source/licensing charges, if applicable + integration maintenance hours × rates + match-review hours × rates + security and expert review. Monthly contribution = fee − monthly cost. Quote initial access assessment and setup separately. Source charges, permitted uses, review burden, price and clients per worker remain unknown. Compare with the existing KYC/screening vendor; public reporting of blocks is not a commercial data licence.
Payer-Pattern Review
Mechanism and decisive uncertainty: aggregate stable payer-token activity per merchant and test whether it adds useful leads beyond existing rules. Access, lawful use, token meaning, stability across time and issuers, and coverage must be established. Transaction IDs cannot be converted into payer IDs. A token does not necessarily represent a unique person. No device or IP feed is assumed.
Define features before testing. For example, top-payer share = eligible transactions associated with the five most frequent payer tokens ÷ all eligible transactions in that merchant’s measurement window. Specify treatment of merchants with fewer than five tokens, unknown tokens, refunds and reversals. Calculate coverage separately: transactions with usable tokens ÷ all eligible transactions. Do not treat incomplete coverage as a complete payer distribution. Concentration and recurrence are hypotheses, not established gambling indicators.
Pilot: one authorised provider and an approved historical dataset. Use an earlier period for feature development and a separate later period for evaluation, with dates and merchant eligibility fixed before inspection. Use only information available at each scoring time. Start four weeks of prospective shadow observation only after access and data checks pass. Do not tune and evaluate on the same labelled episodes. Existing amount/time rules are the comparator, using the same eligible population, timing and review capacity.
Measures and denominator: additional independently supported escalations per fixed analyst-hour and per reviewed case; duplication with current alerts; legitimate cases unnecessarily escalated; unresolved and unreviewed cases; and coverage across the full eligible population. Review a documented sample below both ranking cutoffs to assess selection effects. Evaluate at merchant-episode level; many transactions from one incident are not independent incidents. Keep suspected, confirmed, legitimate and unresolved outcomes distinct. Without adequate independent labels, do not claim sensitivity, recall or a gambling-detection AUC.
Decision rule: agree the minimum useful incremental escalation yield and maximum extra review burden with the partner before evaluation. Continue only if the registered comparison shows an improvement within the same capacity and tolerable uncertainty. Stop or redesign if tokens are unavailable, unstable or too incomplete, no incremental useful signal appears, or unresolved work grows. This pilot cannot establish population prevalence, lawful use in another organisation, prevented losses or the effect of blocking payments.
Buyer and economics: the provider’s fraud team might pay an analytics team for an incremental review signal. Demand is unverified. Recurring sale unit: one provider-month with specified data coverage, scoring frequency and review capacity. Monthly cost = pipeline/compute/security + tuning/support hours × rates + incremental analyst-review hours × rates + recurring specialist review. Monthly contribution = fee − monthly cost. Quote data-access assessment and initial development separately. Rates, hours, usable coverage, incremental yield, price and clients per worker are unknown. Compare the full cost with extending the provider’s existing fraud stack. More alerts or national account-block totals do not establish value.
Stage and method
Stage: hypotheses. Systematic Inventive Thinking informed three different uses of existing steps or relationships. None has been field-tested or endorsed by the named institutions. One idea’s evidence or results would not validate the other two.
Leave a Reply