Transaction Monitoring for Payment Companies and E-Wallets: A Practical Guide
Your alert queue is 800 deep. Your compliance team is three people. It is Monday morning, and PayNow settlements have been running since 6 AM.
This is not a bank CCO's problem. A bank CCO has a 30-person team, a legacy core banking system that batches transactions overnight, and customers whose transactions average thousands of dollars. You have real-time rails, high-volume low-value transactions, and customers who are often more anonymous at onboarding than any bank customer would be. The regulator, however, is looking at both of you with the same rulebook.
That asymmetry — same obligations, entirely different operating context — is where transaction monitoring for payment companies breaks down. The systems that banks deploy were built for bank-shaped problems. Payment companies have different transaction patterns, different fraud vectors, and different compliance team capacities. A system calibrated for a retail bank will generate noise at a scale that makes genuine detection nearly impossible for a small compliance team.
This guide covers what AML transaction monitoring for payment companies and e-wallet operators actually requires in the APAC context — and where the gaps are most likely to cause problems.

Why Payment Companies Face Different TM Challenges Than Banks
The difference is not just volume. It is the combination of volume, speed, transaction size, customer anonymity, and team size — all at once.
Transaction volumes and per-transaction values create a false-positive problem at scale. A rule-based system set to flag transactions above a threshold will generate a manageable number of alerts for a bank processing 50,000 transactions per day at an average value of SGD 3,000. Apply the same logic to an e-wallet operator processing 500,000 transactions per day at an average value of SGD 45, and the alert volume scales disproportionately. Most of those alerts are noise. At 95% false positive rates — which is not unusual for legacy rule-based systems applied to high-frequency, low-value transaction patterns — a three-person compliance team cannot triage what the system produces.
B2C and B2B exposure run simultaneously. Many payment companies serve both retail customers and merchants. The transaction patterns for each are completely different. A merchant receiving 300 settlements in a day looks anomalous by consumer account standards. A retail customer sending five PayNow transfers to five different individuals looks like normal bill-splitting. When both populations sit in the same monitoring environment with the same rules, the rules are wrong for everyone.
Real-time rails are irrevocable. NPP in Australia, PayNow and FAST in Singapore, FPX and DuitNow in Malaysia, InstaPay in the Philippines — all of these settle within seconds. There is no post-settlement hold. If a transaction is suspicious, the only point of intervention is before the money moves. Batch monitoring systems — which review transactions after they have settled — are structurally inadequate for payment companies operating on instant rails. This is not a performance issue; it is an architecture issue.
Mule account layering and APP scams concentrate at payment companies. Payment companies are often the first point of fund movement after a victim transfers money. Authorised push payment (APP) scams work because the victim initiates the transfer themselves — the transaction looks legitimate from a technical standpoint. The only way to detect it is by identifying the pattern: transaction to a new payee, atypical transfer amount for this customer, inconsistent with the customer's normal behaviour. At scale, across an anonymised customer base, this requires behavioural monitoring that most rule-based systems cannot do.
A three-person compliance team cannot triage 800 alerts per day. This is arithmetic. At 8 hours per working day, 800 alerts means 36 seconds per alert. That is not compliance — it is box-ticking.
APAC Regulatory Obligations for Payment Companies
The headline fact here is this: in most APAC jurisdictions, the AML monitoring obligation for licensed payment companies is functionally equivalent to the obligation for banks. What differs is the compliance infrastructure available to meet it.
Singapore (MAS). Payment service providers licensed under the Payment Services Act 2019 — both Major Payment Institutions (MPIs) and Standard Payment Institutions (SPIs) — must comply with MAS Notice PSN01 (for digital payment token services) and MAS Notice PSN02 (for other payment services). The CDD threshold for e-money accounts is SGD 5,000 on a cumulative basis — lower than the threshold applied to bank accounts. MAS expects real-time monitoring capability for account takeover and mule account detection. For detail on the PSA licensing framework and its AML implications, see our article on the Payment Services Act Singapore AML requirements.
Australia (AUSTRAC). Non-bank payment providers registered as remittance dealers or under a Designated Service category face the same Chapter 16 obligations as banks under the AML/CTF Act 2006. The monitoring obligation — transaction monitoring, threshold-based reporting, suspicious matter reports — is identical. The compliance team at the payment provider is not.
Malaysia (BNM). E-money issuers under the Financial Services Act 2013 must comply with BNM's AML/CFT Policy Document. Tier 1 e-money accounts — which carry a wallet balance limit of MYR 5,000 — still require CDD and ongoing transaction monitoring for anomalies. Tier 1 status does not reduce monitoring obligations; it limits what the customer can hold, not what the institution must do.
Philippines (BSP). Electronic money issuers (EMIs) are classified as covered persons under the Anti-Money Laundering Act (AMLA). BSP Circular 706 applies. EMIs must file suspicious transaction reports (STRs) with the Anti-Money Laundering Council (AMLC). The compliance infrastructure that most Philippine EMIs operate with is substantially smaller than what large banks field — but the reporting obligation is the same.
Five Specific TM Requirements for Payment Companies
Generic TM system documentation lists capabilities. What payment companies actually need is more specific.
1. Pre-settlement transaction screening. Payment companies on instant rails need to screen transactions before they clear. This is not optional — it is the only window where intervention is possible. A system that reviews yesterday's transactions overnight is useless for a PayNow or FAST operator. The architecture requirement is real-time, pre-settlement processing.
2. Velocity monitoring across account networks. Mule networks do not operate through single accounts making large individual transfers. They operate through networks of accounts making many small transfers in tight time windows. Detecting this requires monitoring velocity patterns across linked accounts — not just flagging individual transactions that exceed a threshold. Account-to-account linkage analysis, combined with velocity monitoring over rolling time windows, is the detection mechanism. Rule-based systems that operate on individual transaction thresholds miss this pattern entirely.
3. Merchant monitoring. Payment companies providing B2B settlement services need to monitor merchant accounts separately from retail customer accounts. A merchant processing 400 transactions per day with a consistent average transaction value is normal. The same merchant processing 400 transactions per day where 30% are refunds, or where the transaction pattern shifts abruptly over a 48-hour window, is not. Merchant monitoring requires typologies and thresholds built specifically for merchant transaction patterns.
4. Account takeover detection. Payment companies — particularly fintechs and e-wallet operators — face account takeover attempts at higher rates than traditional banks because authentication standards at many providers are weaker. Account takeover detection requires monitoring for behavioural deviations: new device, new location, unusual transfer amount, transfer to a payee the account has never used. These signals need to be evaluated in combination, in real time, before settlement occurs.
5. Cross-border corridor monitoring. A large proportion of payment companies in APAC serve remittance customers. Cross-border flows require corridor-specific typologies — the risk profile of a transfer from Singapore to a Philippines bank account is different from a transfer within Singapore, and different again from a transfer to a jurisdiction with elevated FATF risk ratings. A single generic threshold applied to all cross-border transfers produces alerts that reflect geography rather than actual risk patterns.

What Good TM Looks Like for a Payment Company
The gap between what most payment companies are running and what good transaction monitoring looks like is large. Here is what it actually requires.
Pre-settlement processing across all major APAC instant rails. NPP, PayNow, FAST, FPX, DuitNow, InstaPay. The system needs to operate on the same timeline as the rail — which means pre-settlement, not batch.
False positive rates below 85% in production. Many legacy systems running on payment company transaction data operate at 95% false positive rates or above. At a three-person compliance team, the difference between 95% and 80% is the difference between a team that is permanently behind and a team that can do actual investigations. For a detailed overview of the technical factors that drive false positive rates, see our complete guide to transaction monitoring.
Explainable alert logic. When a compliance analyst opens an alert, they need to understand within 60 seconds why the system flagged it. Opaque model outputs — "risk score: 87" with no explanation — require the analyst to reconstruct the reasoning from raw transaction data. That adds 5–10 minutes per alert. At 100 alerts per day, that is 8–16 hours of analyst time that could be spent on actual investigation. Alert explanations should name the specific pattern or scenario that triggered the flag.
Thresholds calibrated to payment company transaction patterns. A threshold set for a retail bank will fail in a payment company environment. The average transaction value, velocity norms, and customer behaviour patterns at an e-wallet operator are structurally different from a savings account holder at a bank. Thresholds need to be set against the institution's own transaction data — and they need to be adjustable by compliance staff without requiring a vendor engagement.
Scenario coverage for the specific vectors that payment companies face. APP scam detection, mule account network identification, account takeover, cross-border corridor monitoring, and merchant anomaly detection. These are not edge cases for payment companies — they are the primary financial crime exposure.
See the Transaction Monitoring Software Buyer's Guide for a structured framework on evaluating vendors against these criteria.
How Tookitaki FinCense Fits the Payment Company Context
FinCense is deployed at payment institutions across APAC — e-wallet operators, licensed payment service providers, and remittance companies. The architecture was built for the payment company context, not adapted from a bank deployment.
Pre-settlement processing. FinCense processes transactions in real time across NPP, PayNow, FAST, FPX, DuitNow, and InstaPay. The system evaluates each transaction before settlement against the full scenario library — not as a batch job at the end of the day.
Trained on payment institution data. FinCense's detection models are trained using federated learning across a network that includes payment institutions, not only bank data. A model trained exclusively on bank transaction patterns will misread the normal behaviour of an e-wallet customer base. The training data matters for false positive rates — which is why FinCense has reduced false positives by up to 50% compared to legacy rule-based systems in production deployments at payment companies.
Over 50 scenarios covering payment-specific vectors. APP scam detection, mule account network analysis, account takeover patterns, cross-border corridor typologies, and merchant anomaly detection are all in the standard scenario library. These are not add-ons; they are part of the base deployment.
No in-house quant team required. Compliance staff can configure thresholds and adjust scenario parameters directly. The system generates plain-language alert explanations that a compliance analyst — not a data scientist — can act on. At a three-person compliance team, this is the difference between a usable system and a system that is technically running but practically unmanageable.
Scales from licensed payment institutions to large e-wallet operators. The architecture does not require a different deployment for a 50,000-transaction-per-day provider versus a 5,000,000-transaction-per-day operator. The monitoring logic, the scenario library, and the compliance workflows are the same.
If you run compliance at a payment company, an e-wallet operator, or a licensed payment service provider in APAC and your current TM system was either built for a bank or has never been calibrated against your actual transaction data — the problem is not going away on its own.
Book a demo to see FinCense running against payment company transaction patterns, on the specific rails your institution operates, in the regulatory environment you are actually accountable to. The conversation takes 30 minutes and is specific to your payment rails and jurisdiction — not a generic product walkthrough.
Experience the most intelligent AML and fraud prevention platform
Experience the most intelligent AML and fraud prevention platform
Experience the most intelligent AML and fraud prevention platform
Top AML Scenarios in ASEAN

The Role of AML Software in Compliance

The Role of AML Software in Compliance








