Payment providers in Indonesia need to spot shop accounts used for illegal gambling, but unusual early sales can also be legitimate. Could a supervised review period help them decide when to raise payment limits?
The Problem
A shop passes registration checks and begins accepting digital payments. Its paperwork describes the business, but the provider has little history of how that business will actually use the account. What should happen if its first payments look different from the activity it declared?
The question matters for QRIS, Indonesia’s standard for QR-code payments. Fintech News Indonesia reported Bank Indonesia’s call for closer merchant checks and continuing monitoring in October 2026. The report gives the example of a snack seller receiving repeated, same-amount payments at midnight after the shop had supposedly closed. That is activity to investigate, not proof of gambling. [1]
Registration and later monitoring serve different purposes. Bank Kalteng’s merchant-app description explains verification before activation, but it does not describe the bank’s internal risk controls. Bank Indonesia’s regulatory summary expressly includes ongoing due diligence for the providers within its scope. We cannot infer that activation means a merchant is permanently trusted or that providers only react through blacklists. [2] [3]
The narrower problem to investigate is whether a particular provider connects a new merchant’s early payment activity to its decisions about higher limits. If those decisions happen without a review of relevant activity, the provider may expand access while questions remain unresolved. If it responds too aggressively to ordinary fixed-price or late-night sales, it may instead hold back a legitimate business.
The source reporting establishes the oversight concern. It does not establish how often that decision gap occurs, or that newly registered merchants are the main route for gambling-payment misuse. Those are questions for a pilot partner.
What Could Work?
An Early Sales Review could give a provider a defined period to examine a newly activated merchant’s activity before approving a higher payment limit, where its existing rules and agreements permit that decision.
The provider’s risk team might pay a small compliance-technology team to connect transaction records, review cases and limit-change approvals. It would be buying a more consistent decision process, if that process improves on its current tools. Demand, pricing and the value of the improvement remain unverified.
Identity and business verification would remain in place. Early sales would add evidence to the later decision; they would not become the sole test of whether a merchant can be trusted.
How It Could Work
Choose one provider that already has an authorised way to review merchant limits. Start by mapping its actual account states, data and approval responsibilities. If it has no suitable limit-change process, the proposed control needs redesign before implementation.
An illustrative version would observe the first 30 days after a merchant is activated with that provider. The clock would begin at the recorded activation time, even if the merchant makes no sales. A high transaction count would not end the review early or automatically earn a higher limit.
Configurable rules would identify activity worth examining: repeated amounts, sudden changes in payment frequency, or trading that appears inconsistent with reliable business information. Missing or outdated trading hours would remain unknown. A declared opening time would provide context, not an automatic exemption from review.
The system would assemble a case showing the payments, the reason for concern, data limitations and the merchant information available at that time. An authorised reviewer would decide whether to approve a requested increase, seek more information or follow an existing escalation procedure. Credible concerns would enter the normal response process promptly, rather than wait for a pattern to persist for several days.
At the end of the period, the provider would record a reasoned outcome. Sparse activity would be recorded as insufficient evidence, with a defined follow-up route rather than an indefinite, unexplained status. Ordinary monitoring would continue after the introductory review; completing it would not certify future behaviour.
The inventive move is to separate two decisions: allowing an appropriately verified merchant to begin using the service, and deciding whether subsequent evidence supports a higher limit. The transaction stream gains a role in the second decision without replacing the checks required for the first.
Why It Might Work
A scheduled review could give early concerns a clear owner and a decision point. It could also make it easier to see why a limit was raised, left unchanged or referred for further assessment.
That benefit depends on more than generating alerts. The rules must identify useful questions, reviewers must have time to resolve them, and the eventual decision must matter to the merchant’s actual access. A report that no one acts on would not complete the mechanism.
This is not an empty market. Stripe’s indexed support material, for example, describes account reverification linked to volume thresholds and risk signals. That does not establish an equivalent QRIS service in Indonesia, but it does show why the partner’s own tools and existing vendors need checking first. [5]
What Could Get in the Way?
A new fixed-price food stall could produce repetitive payments without wrongdoing. A late-night business could look unusual against a poor profile. Conversely, an abusive account could imitate ordinary trading during the review and change afterwards. PPATK describes adaptive payment behaviour and merchant-identity misuse, but its findings do not validate a first-month screening rule. [4]
The provider may lack usable records, enough reviewers or authority for the proposed limit changes. A human decision does not remove those constraints. Nor does an anomaly establish that an account is linked to gambling.
The service would also process potentially identifying merchant and transaction information. Its purpose, access, retention and responsibilities need review under the applicable framework, including Indonesia’s Personal Data Protection Law. A merchant-specific limit cannot simply be inferred from a general QRIS transaction limit or another provider’s practice. [3] [6]
The first test should therefore run without changing live limits, delaying activation, withholding payouts or replacing existing monitoring. Any later trial of actual restrictions would require a separate operational and legal assessment.
What Would It Take to Find Out?
First observe the partner’s current limit-review process. Does it already use early transaction activity? Which decisions are difficult, and what evidence is missing? If the present system already does the job, configuration or staff training may be more useful than a new product.
For a shadow pilot, enrol newly activated merchants over two weeks and follow every enrolled merchant for a full 30 days. Include legitimate fixed-price and late-night businesses. Newly activated means new to this provider; it does not imply that the shop has never used another payment service.
The prototype would produce proposed review cases and limit decisions while the provider’s normal process continues unchanged. Compare both approaches using the same information available at the same point in each merchant’s history. Independent reviewers would assess whether the cases warranted escalation or further information. An unresolved case would remain unresolved, not be counted as legitimate or gambling-linked.
Measure whether useful concerns reach review earlier, how much staff work is required, how many legitimate businesses would face unnecessary extra scrutiny, and whether cases reach a supported decision. Record merchants with no activity, missing data, unfinished cases and no request for a higher limit.
Before testing, agree what improvement would justify the extra workload. Continue only if the registered target is met without worse decision quality or a growing unresolved queue. If reliable outcomes are too scarce, report feasibility rather than a detection rate. Shadow results could justify further investigation; they could not prove that changing limits prevents illegal payments.
Who Could Make It Work?
A provider’s merchant-onboarding lead, payments engineer and experienced compliance analyst could map the workflow and build the first test. A data analyst would define the evaluation and check whether the rules add value beyond existing monitoring. Qualified privacy and payments-regulatory advisers would need to review the proposed processing and any later changes to merchant access.
No named provider has agreed to participate. If you manage merchant accounts, what evidence do you currently require before raising a new business’s payment limits—and where does that decision become difficult?
Research Notes
Stage: hypothesis. The proposed review, demand and benefits have not been tested. The pilot concerns a specific provider’s decision process, not a claim that all payment companies lack ongoing monitoring.
Sources and provenance
[1] Fintech News Indonesia — “Indonesia Balances QRIS Cross-Border Expansion with Merchant Oversight,” 22 October 2026. Read the original selected story. Full publisher text read and retained on 23 October 2026 through direct HTTPS retrieval; the web tool could not open the URL. This secondary report attributes the merchant-oversight remarks to ANTARA. It supports the attributed call for closer checks and continuing monitoring. It does not establish an introductory tier, automatic cap, report template or provider-specific workflow gap. The separate cross-border sandbox timeline is not a compliance deadline for this idea.
[2] Bank Kalteng — “QRIS Merchant by Bank Kalteng,” publisher’s Google Play listing, updated 14 May 2026. Read the listing. Full description read and retained on 23 October 2026. Describes registration, verification, activation and merchant-facing transaction visibility. It is not a description of the bank’s internal fraud controls and cannot establish that monitoring ends after activation. The bank is not a pilot partner. Marketing statements and developer data-safety declarations are not independent audits or permission for this proposed processing.
[3] Bank Indonesia — PBI 10/2024 official regulatory summary, 31 December 2024. Read the original summary. Official indexed summary checked on 23 October 2026, including ongoing due diligence, scope and updating information. Direct page retrieval was intermittent and subsequent attempts timed out. The summary is evidence against the premise that monitoring is inherently a one-time check. It does not establish this provider’s licence, authority for a merchant-specific tier, contractual terms or reporting acceptance. Qualified review of the complete applicable rules is required before an intervention.
[4] 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 substantive release read through web retrieval on 23 October 2026; direct archival request returned an HTTP error. Describes smaller, frequent payments, misuse of merchant identities/purposes and improved detection. Its QRIS percentage of deposit transaction counts is different from the share of deposit value. Neither aggregate establishes prevalence among newly activated merchants, expected pilot losses or the effectiveness of an early review.
[5] Stripe — “Why do my connected accounts need reverification?” Read the original support page. Publisher’s indexed text checked on 23 October 2026; no publication date displayed. It lists volume thresholds and risk signals among reasons for reverification. Full web retrieval failed with an unsupported content-type response; direct retrieval returned a JavaScript shell. This limited comparison does not establish identical functionality, Indonesia availability, QRIS support or measured effectiveness. It identifies an existing lifecycle-risk practice to investigate, not a recommendation to buy the product.
[6] Law 27/2022 on Personal Data Protection. Read the official BPK record. Metadata and abstract checked on 23 October 2026; listed as in force. Identifies the processing framework, not legal clearance. The partner must establish purpose and basis, roles, access, minimisation, retention, security and any external processing arrangements. Replacing names with codes or keeping data inside the company is not assumed to settle those questions.
Causal hypothesis and dependencies
Source checked: monitoring over time is part of the reported oversight expectation [1] and the official summary [3]. A merchant-facing activation description [2] does not prove absent internal controls. PPATK’s aggregate findings [4] do not establish that new QRIS merchant identifiers are the dominant entry route for misuse.
Unverified local need: relevant early transaction evidence is not consistently considered before a provider grants higher merchant limits. Observe actual workflows, existing rules, staffing and authority. The partner must have an authorised, meaningful limit-review decision; otherwise this control point does not exist and the mechanism needs redesign. Do not assume an aggregator, issuer and acquiring provider have interchangeable roles or access.
Proposed chain: collect authorised early merchant activity → form an explainable review case → an authorised person reaches a supported limit decision → a later intervention might reduce unjustified expansion of access. Shadow observation tests the first three steps and workload. It cannot establish the final effect on misuse or losses, because live access is unchanged. An alert or a generated document alone is not the claimed decision outcome.
The records needed include a reliable merchant identifier, activation event, transaction timestamps/status/amount, relevant business information and the actual limit-decision history. Check availability, late arrival, time zones, duplicates, reversals and profile changes. A transaction visible to a merchant does not prove that a third-party team can obtain a usable provider-level feed. No payer device/IP information or regulator suspect-list access is assumed. An internal assessment or referral is not automatically an independently confirmed gambling outcome.
Review policy and merchant treatment
Thirty days is an illustrative observation horizon, not a sourced standard or a proven sufficient period. Define the activation event and use elapsed time consistently. Do not end observation at a transaction-count cutoff: a high-volume merchant could otherwise complete the period before a persistence rule has any opportunity to act. No mandatory three-day delay applies to credible concerns. Existing response, reporting and escalation obligations remain in force.
Proposed outcomes are a reasoned increase decision, request for further information or referral through existing procedures. Lack of an alert is not clearance. Lack of sales is not positive evidence. Keep a dated, owned follow-up for insufficient evidence and a process for correcting merchant information and reviewing decisions. Any explanation to a merchant must respect applicable confidentiality and reporting duties. Do not create an indefinite unexplained status.
The prototype runs read-only and in shadow mode. It does not remove identity checks, change activation, alter limits or settlement, hold funds, contact merchants or file regulator reports. A future intervention must specify lawful authority, merchant terms, the exact control, approval/review responsibilities, implementation checks and remedies for errors. A human in the process does not itself provide those permissions. Standard monitoring continues after the introductory period and after any limit increase.
Existing alternatives and distinctive scope
Compare the partner’s present onboarding risk tiers, transaction alerts, merchant reviews, limit-change approvals, case-management software and staff runbooks. Vendor lifecycle-risk and reverification tools are relevant comparators [5]. The proposed increment is a defined early observation period tied to a particular later limit decision. It is not the invention of ongoing monitoring, a universal gambling classifier or a validated replacement for an internal risk team.
Check whether provider configuration can implement the same workflow at lower cost. Machine learning is not required by the proposed rule-based prototype, but integration, security, data quality, support and experienced review still require work. The lack of a data-science team is not assumed from company size. No regulator-ready evidence format or automatic licence protection is claimed.
Pilot and falsification
Population and selection: one authorised provider and a registered cohort of merchants activated during a two-week enrolment interval. Include ordinary businesses with fixed prices and evening trading, alongside other relevant categories. Do not demand proof that these merchants have never used another provider. Record every eligible activation, inclusion/exclusion reason and unavailable record. Use a consecutive cohort or another documented selection rule fixed before observing outcomes.
Time zero and follow-up: recorded activation with the provider. Follow every enrolled merchant for the same 30-day window; the last enrollee’s window ends 30 days after its activation, not four weeks after the first enrollee. Close collection only after that window. Later labels have their own date and ascertainment horizon. Withdrawals, closure, outages and missing observation remain in the cohort accounting; silence is not a clean outcome. Continuous existing monitoring is never suspended.
Development and comparator: configure rules on a separate earlier dataset, then freeze them before evaluation. Compare current and proposed reviews using the same merchant/time snapshots and information actually available then. Do not feed future referrals or later outcomes into historical case generation. Vary which reviewers receive each case format to limit learning effects. Provider decisions and labels used for tuning cannot also serve as an unqualified independent test of the same rules.
Reference decisions: qualified reviewers, separate from rule development and blind to the prototype’s recommendation where feasible, assess whether each case warranted escalation, further information or an ordinary decision under the partner’s policy. This reference judges decision support; it does not convert a suspicious pattern into proof of gambling. Distinguish independently corroborated misuse, supported legitimate explanations and unresolved status. If meaningful reference judgments cannot be made, report feasibility only.
Primary measures: proportion of registered, reference-escalation episodes brought to a supported review outcome within a pre-agreed response budget; elapsed time from the first relevant evidence available to each supported disposition; and total analyst/preparation effort across all assigned cases. Report no-triggered, missing-data and unfinished cases, including timeouts, rather than computing a reassuring mean only among completions. Use the same event definitions and opportunity set for current and proposed processes. Multiple alerts for one merchant episode are not independent incidents.
For merchants with an actual higher-limit request, separately compare whether useful evidence reached the reviewer before the decision. Keep all requests, including declined, withdrawn and unresolved requests, in that denominator. Do not imply that a merchant without a request experienced a delayed increase. Proposed shadow outcomes have no observed activation-delay or lost-sales effect because access was not changed.
False alarms and burden: unnecessary escalations divided by all independently supported legitimate merchant episodes; fraction of alerts found unnecessary divided by all alerts; unresolved episodes and additional review hours, each reported separately. The second fraction is not the statistical false-positive rate. Keep merchants with no transactions and those lacking independent status visible; do not silently classify them as legitimate. Compare rankings at the same review capacity and inspect a documented sample below the alert cutoff to avoid selection bias.
Decision rule: before evaluation, the partner sets a worthwhile improvement in supported review completion or timeliness, a maximum added workload and acceptable decision-quality limits. Do not select these after seeing results. Continue only if the registered comparison meets them without more missed reference escalations or a growing unresolved queue. An agreed timing/labour target cannot be declared met while assigned cases needed for that comparison remain unfinished. Stop or redesign if records or authority are unavailable, rules mainly duplicate current alerts, legitimate businesses receive excessive unnecessary scrutiny, or useful evidence arrives after the relevant decision. Small samples and scarce confirmed outcomes limit conclusions; no universal detection percentage is promised.
This pilot cannot establish prevented gambling, actual loss reduction, the effect of lower limits, customer retention, regulator acceptance or lawful operation at another company. Testing a real access change would be a later, separately authorised study with merchant impacts and implementation effectiveness measured directly.
Commercial hypothesis and units
The potential buyer is the provider’s risk/compliance function. It might pay a compliance-technology team for integration, case generation and ongoing support if the result improves its existing decision process. Buyer access, procurement, willingness to pay and the cost of current practice remain unverified. A company’s regulatory exposure is context, not evidence that it will buy this module.
Use one provider-month as the recurring sale unit, specifying activated-merchant cohort volume, integrations, processing frequency, review load and support hours. Treat initial integration, legal/data assessment and rule development as separately priced setup, excluded from recurring costs in this model.
Monthly delivery cost = data/infrastructure/security + integration maintenance hours × fully allocated rates + review/tuning/support hours × rates + recurring specialist advice. Monthly contribution = monthly fee − monthly delivery cost. Record account volumes, usable data coverage, alerts and resolved cases per analyst-hour, support incidents and the number of providers a team can actually serve. Prices, rates, effort, acquisition cost and customer lifetime remain unknown. Cash receipts and review staffing must be sustainable as well as the arithmetic contribution.
Compare total work across engineering, compliance, merchant support and analysts. Faster case creation is not a saving if another team inherits unresolved work. Do not use national account-blocking totals, QRIS market volume or hypothetical licence loss as the buyer’s avoidable cost. Only a later intervention study could estimate financial benefits from changed limits, including mistaken restrictions and displaced activity.
Stage and method
This article develops one conditional seed idea using a separation between initial eligibility and later access decisions. The approach retains required identity checks and continuous monitoring. Source checking and causal revision inform the design; no named institution has endorsed it and no field trial has occurred.
Leave a Reply