New Zealand's anti-money laundering framework did not arrive fully formed. It was built in two deliberate phases.

Phase 1 came into effect from 2013. Banks, non-bank deposit takers, and financial institutions were brought under the Anti-Money Laundering and Countering Financing of Terrorism Act 2009 (the AML/CFT Act). Phase 2 followed between 2018 and 2019, extending obligations to lawyers, conveyancers, accountants, real estate agents, trust and company service providers, and casinos.

The result is one of the broadest reporting entity frameworks in the Asia-Pacific region. A law firm advising on a property transaction is a reporting entity. So is an accountancy practice handling company formations. So is a cryptocurrency exchange. If you are a compliance officer or senior manager at any organisation in these sectors, the AML/CFT Act applies to you — and the obligations are substantive.

Understanding what the Act requires is not optional. Three separate supervisory agencies actively examine reporting entities, and enforcement actions have been taken across all three sectors.

The AML/CFT Act 2009 — Primary Legislation and Key Amendments

The primary legislation is the Anti-Money Laundering and Countering Financing of Terrorism Act 2009. It is the single statute that governs all AML/CFT obligations for reporting entities in New Zealand.

The Act has been amended several times since its original enactment. The most significant structural change came in 2017, when amendments extended the framework to Phase 2 entities — the DNFBPs (designated non-financial businesses and professions) that came on stream from 2018 onwards. A further set of amendments was passed in 2023 via the Anti-Money Laundering and Countering Financing of Terrorism (Definitions) Amendment Act 2023, which updated the definitions framework to bring virtual asset service providers (VASPs) and digital assets into clearer alignment with FATF standards.

The Three-Supervisor Structure

New Zealand uses a split supervisory model that is uncommon in the Asia-Pacific region. Most APAC jurisdictions assign AML supervision to a single financial intelligence unit or prudential regulator. New Zealand has three:

• Financial Markets Authority (FMA): Supervises financial markets participants, licensed insurers, and certain non-bank financial institutions.
• Reserve Bank of New Zealand (RBNZ): Supervises registered banks and non-bank deposit takers.
• Department of Internal Affairs (DIA): Supervises lawyers, conveyancers, accountants, real estate agents, trust and company service providers, and casinos.

Each supervisor has its own examination approach and publication practice. A law firm subject to DIA supervision operates under the same Act as a bank supervised by the RBNZ — but the examination focus and sector context will differ. Reporting entities need to understand which supervisor they report to, because guidance, templates, and examination priorities vary.

Who Is a Reporting Entity in New Zealand

The AML/CFT Act defines "reporting entity" across three broad categories.

Financial institutions include registered banks, non-bank deposit takers, life insurers, money changers, and remittance service providers. These entities have been subject to the Act since Phase 1.

Designated non-financial businesses and professions (DNFBPs) include lawyers (when conducting relevant activities such as conveyancing, company formation, or managing client funds), conveyancers, accountants, real estate agents, trust and company service providers, and casino operators. These entities have been captured since Phase 2.

Virtual asset service providers (VASPs) — including cryptocurrency exchanges, custodian wallet providers, and other businesses facilitating digital asset transfers — were brought into the framework from June 2021 following amendments to the Act.

The breadth of this list matters. Unlike jurisdictions where AML obligations fall almost exclusively on banks and financial institutions, New Zealand compliance officers in professional services firms face the same core obligations as a registered bank. The complexity of building an AML/CFT programme may differ, but the legal requirements do not.

The Seven AML/CFT Programme Requirements

Under Section 56 of the AML/CFT Act, every reporting entity must have a written AML/CFT programme. The programme is not a theoretical document — it must reflect how the organisation actually operates, and it must be implemented in practice.

The seven required elements are:

1. Risk assessment. A documented assessment of the money laundering and terrorism financing risks posed by the entity's products, services, customers, and delivery channels. This must be reviewed and updated when material changes occur.
2. Compliance officer. A designated AML/CFT compliance officer must be appointed. This role can be filled internally or by an approved external provider. The compliance officer is accountable for day-to-day programme management and regulatory reporting.
3. Customer due diligence (CDD) and enhanced due diligence (EDD) procedures. Written procedures covering how the entity identifies customers, verifies their identity, and applies EDD where required. See the section below for what this means in practice.
4. Ongoing CDD and account monitoring. Continuous monitoring of transactions against customer risk profiles. The Act does not permit periodic-only review — monitoring must be ongoing.
5. Record keeping. Records of CDD, transactions, and reports must be retained for a minimum of five years.
6. Staff training. All relevant staff must receive AML/CFT training appropriate to their role. Training records must be maintained.
7. AML/CFT audit. An independent audit of the AML/CFT programme must be conducted at least every two years for most entities. This is a statutory requirement under Section 59 of the Act. The auditor must be independent of the compliance function.

CDD Requirements in Practice

New Zealand's CDD framework follows a risk-based approach consistent with FATF Recommendations, but the specific requirements are set out in the AML/CFT Act and its regulations.

Standard CDD applies to all customers at onboarding and must include identity verification using reliable, independent source documents. For individuals, this means a government-issued photo ID plus address verification. For legal entities, it means a certificate of incorporation and — critically — verification of beneficial ownership. Understanding who ultimately owns or controls a company or trust is a requirement, not an option.

For more detail on what the verification process involves, the complete guide to transaction monitoring covers how identity data feeds into ongoing monitoring workflows. The KYC guide sets out the broader identity verification framework in detail.

Enhanced CDD (EDD) is triggered where the risk assessment or customer circumstances indicate higher risk. EDD triggers under the AML/CFT Act and its associated regulations include:

• Politically exposed persons (PEPs) and their associates
• Customers from jurisdictions on the FATF grey or black list
• Complex or unusual business structures where beneficial ownership is difficult to verify
• Transactions that are inconsistent with the customer's established profile

For EDD customers, the entity must also obtain and verify source of funds and, in some cases, source of wealth. This is not a box-ticking exercise — the documentation must be sufficient to explain the customer's financial activity.

Ongoing monitoring is where many reporting entities fall short. The Act requires continuous monitoring of transactions against customer risk profiles. A quarterly review schedule is not sufficient compliance. Monitoring must be calibrated to detect anomalies as they arise, which in practice means transaction monitoring systems or documented manual procedures that operate at transaction level.

Transaction Reporting Obligations

Reporting entities have two distinct filing obligations with the New Zealand Police Financial Intelligence Unit (FIU).

Suspicious Activity Reports (SARs)

A Suspicious Activity Report must be filed when a reporting entity suspects that a transaction or activity may involve money laundering, terrorism financing, or the proceeds of a predicate offence. There is no minimum threshold — the obligation is triggered by suspicion, not transaction size.

SARs must be filed "as soon as practicable." The Act does not specify a number of business days, but FIU guidance is unambiguous: file without delay. Once a SAR is being prepared or has been filed, the entity must not tip off the customer that a report is being made or that a suspicion exists. Tipping off is a criminal offence under the Act.

Prescribed Transaction Reports (PTRs)

PTRs are required for:

• Cash transactions of NZD 10,000 or above (or the foreign currency equivalent)
• Certain international wire transfers of NZD 1,000 or above

PTRs are filed with the NZ Police FIU. Unlike SARs — which are discretionary in the sense that they require a judgment call on suspicion — PTR filing is mechanical and threshold-based. Every qualifying cash transaction and wire transfer must be reported, regardless of whether the entity suspects anything unusual.

The volume of PTR filings at institutions handling significant cash flows or international payments makes automation a practical necessity rather than a preference.

The Audit Requirement — What Examiners Look For

The mandatory two-year audit under Section 59 is not a light-touch compliance check. It is a substantive review of whether the AML/CFT programme is working in practice. The supervisor — FMA, RBNZ, or DIA — may request the audit report at any time.

An AML/CFT audit must assess:

• Whether the risk assessment is current and accurately reflects the entity's actual customer and product mix
• Whether the written AML/CFT programme is being implemented as documented
• Whether CDD procedures are being followed at the individual account and transaction level — including transaction sampling
• Whether staff training records are complete and training content is appropriate

Audit findings are not optional to address. Where the auditor identifies gaps, the entity must remediate them. Supervisors will look at both the audit report and the entity's response to it.

What Regulators Actually Flag

Examination findings across New Zealand reporting entities follow recognisable patterns. The following issues appear repeatedly in supervisory communications and enforcement actions:

Outdated risk assessments. Risk assessments that were prepared at the time of onboarding to the Act and have not been updated since. If the entity's products, customer base, or delivery channels have changed and the risk assessment has not been revised to reflect this, it is not compliant.

Incomplete CDD for legacy customers. Entities that onboarded Phase 2 customers before their AML/CFT obligations commenced often have documentation gaps at account level. Remediating legacy CDD files is a known, ongoing issue across DNFBPs.

Periodic monitoring treated as ongoing monitoring. Quarterly customer reviews do not satisfy the ongoing monitoring obligation. Regulators have been explicit about this distinction.

Beneficial ownership gaps for trusts and complex structures. Verifying who ultimately controls a discretionary trust or a multi-layered corporate structure is difficult. Leaving this as "pending" or accepting incomplete documentation is one of the more frequently cited CDD failures.

PTR and SAR filing delays. Smaller DNFBPs — accountancy practices, law firms, real estate agencies — that are less familiar with the FIU reporting system often delay filings or miss them entirely. The obligation does not diminish because an entity is small or because the compliance team is not specialised.

How Technology Supports AML/CFT Compliance for NZ Reporting Entities

For financial institutions handling significant transaction volumes, manual transaction monitoring is not a workable approach. The PTR threshold at NZD 10,000 for cash transactions requires automated cash monitoring and report generation. SAR filing requires a case management workflow — alert review, investigation documentation, decision rationale, and a filing record that can be produced to a supervisor on request.

Automated transaction monitoring systems must apply New Zealand-specific typologies and thresholds, not just generic international rule sets. The NZ customer risk profile and the specific triggers in the AML/CFT Act differ from those in Australian or Singaporean frameworks. A system calibrated for another jurisdiction will not deliver accurate detection for a New Zealand entity.

For the two-year audit, AML/CFT systems need to produce exportable audit trails. Auditors will want to see alert volumes, disposition decisions, and calibration history. A system that cannot generate this output creates a significant gap at audit time.

When evaluating technology options, the Transaction Monitoring Software Buyer's Guide provides a structured framework for assessing vendor capabilities against your specific obligations and transaction profile.

Tookitaki's FinCense for New Zealand Compliance

New Zealand's AML/CFT framework places specific, auditable obligations on reporting entities across sectors that most AML platforms were not designed to support. FinCense is built to address this directly — with configurable typologies for NZ reporting obligations, PTR automation, SAR case management, and audit-ready transaction trails.

If you are building or reviewing your AML/CFT programme ahead of your next supervisor examination or two-year audit, talk to our team. We work with reporting entities across financial services and professional services sectors in New Zealand and across the APAC region.

Book a demo to see how FinCense supports New Zealand AML/CFT compliance — or speak with one of our experts about your specific programme requirements.

It is 9:30 on a Tuesday. The overnight batch run has finished. The alert queue shows 412 cases requiring review. Your team of five analysts has roughly six hours of productive investigation time between them today.

Do the arithmetic: each analyst needs to process 82 alerts to clear the queue before the next batch runs. At 20 minutes per alert — if the review is thorough — that is 27 hours of work for five people. It cannot be done properly. It will not be done properly.

And buried somewhere in those 412 alerts are the 20 or so that actually matter.

This is not a hypothetical. APAC compliance teams at banks, payment service providers, and fintechs describe exactly this operating reality. The false positive transaction monitoring problem is not a technical metric — it is a daily management failure that compounds over time. Analysts triage faster to survive the queue. The real signals get the same two-minute review as the noise. The programme that exists on paper bears no resemblance to what actually happens.

This article is not about what false positives are. If you are reading this, you know. It is about the cost of living with a high AML false positive rate — and the five practical steps that compliance teams use to bring it down.

What a High False Positive Rate Actually Costs

The standard complaint about transaction monitoring alert fatigue is that it wastes analyst time. That framing understates the problem.

Analyst capacity: the numbers are stark. At a 95% false positive rate with 400 alerts per day, 380 are dead ends. At 20 minutes per alert — which is the minimum for a documented, defensible triage — that is 127 analyst-hours per day spent reviewing noise. A compliance team needs approximately 16 full-time analysts doing nothing but alert triage to manage that volume at an adequate standard. Most APAC institutions have two to five.

Missed genuine signals: the hidden cost. The real damage is not the wasted hours — it is what happens to the 20 genuine alerts buried in 380 false ones. When analysts are clearing a 400-alert queue with limited capacity, they cannot give each case appropriate attention. The suspicious transaction that warrants a 90-minute EDD review gets the same 3 minutes as the noise around it. Alert fatigue is not just inefficiency. It is a mechanism for missing financial crime.

Regulatory exposure: backlogs are a finding. AUSTRAC's examination methodology includes review of alert disposition quality and queue backlogs. A compliance programme with a permanent backlog — where cases are not being reviewed within a defensible timeframe — is a programme finding, not merely an operational concern. MAS Notice 626 similarly expects that suspicious transaction monitoring is effective, not just that a system exists. Regulators in both jurisdictions have cited inadequate alert review as an examination failure in enforcement actions. The AML false positive rate problem is a regulatory risk, not a process inefficiency.

Staff turnover: the compounding effect. AML analysts in APAC are in short supply, and the shortage is getting worse as the regulated population expands under frameworks like Australia's Tranche 2 reforms and Singapore's digital banking licensing regime. A team that spends 90% of its time closing dead-end alerts has a retention problem. The analysts who leave are the ones with enough experience to find a role where their work matters. The ones who stay become less effective over time. Institutional knowledge walks out the door.

Why Rule-Based Systems Generate High False Positive Rates

Before addressing the fix, the cause.

Most transaction monitoring platforms in production at APAC banks and payment firms are built primarily on rules — logic statements that fire when a transaction crosses a defined threshold. The problem is not that rules are wrong. Rules are appropriate for known, well-defined typologies. The problem is structural.

Rules go stale. A rule calibrated for the institution's customer population in 2022 reflects transaction patterns from 2022. Customer behaviour changes. New products get launched. Regulatory requirements shift what customers route through which channels. A threshold that was appropriately sensitive at go-live will generate noise within 18 months if it is not recalibrated.

Rules ignore the customer. A rule firing on any international wire above $50,000 treats every customer the same. A high-net-worth client sending a monthly transfer to an offshore investment account triggers the same alert as a newly opened retail account sending the same pattern. The transaction looks identical to the rule — the context is invisible.

Rules cannot anticipate new typologies. When authorised push payment (APP) scams emerged as a dominant fraud vector across Australia and Singapore, every existing rule threshold started triggering on the pattern before teams had time to tune. The spike in false positives from a new typology can last months before calibration catches up.

Vendor defaults are not institution-specific. A transaction monitoring system configured on vendor-default thresholds is calibrated for an imagined average institution — not the specific customer base, geography, and product mix of the institution running it. AUSTRAC has explicitly noted this in published guidance. Running on defaults is not a defensible position under examination.

Five Practical Steps to Reduce False Positives

Step 1: Measure What You Actually Have

You cannot reduce something you have not measured.

Most compliance teams know their total daily alert volume. Few have a breakdown of false positive rate by alert scenario, by customer segment, and by transaction channel. That breakdown is the starting point for any calibration effort.

Pull the last 90 days of alert data. For each alert scenario, calculate the ratio of alerts closed without further action to alerts that progressed to an STR or EDD. That ratio is your scenario-level false positive rate. You will find three or four scenarios generating the majority of your noise — and those are the calibration targets.

This analysis also tells you which scenarios are genuinely earning their place in the rule library and which are generating alerts that no analyst has been able to explain in 12 months. You need that data before you touch a single threshold.

Step 2: Segment by Customer Risk Profile

The same transaction looks different depending on who is sending it.

A rule that fires on any international wire above $50,000 will generate noise for high-net-worth clients and genuine signals for retail customers. The rule is not wrong — it is not differentiated. Risk-segmenting your alert thresholds means applying different parameters to different customer risk tiers.

For a high-net-worth client with a documented wealth source, a history of international transactions, and a stated investment mandate, the threshold for that wire scenario should be materially higher than for a retail account with six months of history. A single institution-wide threshold is a blunt instrument.

This is one of the highest-impact single changes a compliance team can make without replacing its transaction monitoring platform. It requires access to customer risk classification data and the ability to apply segmented parameters — which most modern TM systems support but which most institutions have not configured.

Step 3: Retire Stale Rules

Most transaction monitoring systems accumulate rules over time. New typologies get added. Old ones are almost never removed.

A rule written in 2019 for a fraud pattern that no longer applies is generating alerts that analysts close on sight — and generating them reliably, every batch run, because the condition is always met. That rule is not protecting the institution. It is consuming analyst capacity.

Run an audit of the full rule library. For any scenario with a false positive rate above 98% and zero genuine catches in the past 12 months, retire the rule. Document the decision, the data that supports it, and the review date. AUSTRAC expects evidence that alert thresholds are actively managed — a retirement decision with supporting data is better evidence than a rule that has been silently ignored for three years.

This is standard hygiene. Most compliance teams have not done it because calibration work is not glamorous and implementation backlogs are long.

Step 4: Move from Rules-Only to Hybrid Detection

Rules are deterministic. They fire when conditions are met, regardless of context. A hybrid system combines rules for known, well-defined typologies with behaviour-based models that evaluate the transaction in context.

Machine learning models can factor in variables that rules cannot: the customer's transaction history, peer group behaviour, time-of-day patterns, the channel the transaction is moving through, and the relationship between recent account activity and the triggering transaction. A $50,000 international wire from an account that has never sent an international wire before looks different from the same wire from an account where this is the 12th such transfer this quarter.

The evidence for hybrid detection is not theoretical. Institutions that have moved from rules-only to hybrid architectures consistently report lower false positive rates and higher genuine detection rates simultaneously. Reducing false positives and improving detection quality are not in tension — they move together when the underlying detection logic is more precise.

Both AUSTRAC and MAS have signalled that rules-only monitoring is no longer sufficient for modern financial crime patterns. MAS's guidance on technology risk management and the application of technology-enabled controls is explicit on this point. AUSTRAC's 2023–24 enforcement priorities referenced the need for institutions to move beyond static threshold monitoring. For a complete picture of what modern detection architecture looks like, the complete guide to transaction monitoring covers the detection models in detail.

Step 5: Build Calibration Into Operations, Not Just Implementation

False positive rates drift upward when thresholds are not actively maintained. The calibration done at go-live will not hold for two years.

Build a quarterly calibration review into the compliance programme as a standing process. The review should cover the 10 highest-volume alert scenarios, compare the false positive rate trend over the past quarter, and document threshold adjustments with supporting rationale. The output of each review should be a calibration log entry — a record that the programme is being actively managed.

This documentation serves two purposes. First, it reduces false positive rates by catching threshold drift early. Second, it provides examination evidence. When AUSTRAC or MAS asks for evidence that alert thresholds are calibrated to the institution's risk profile, a quarterly calibration log with supporting data is a substantive answer. A vendor configuration file from 2022 is not.

What Good Looks Like

A well-calibrated AI-augmented transaction monitoring system should achieve below 85% false positive rate in production. That is not a theoretical benchmark — it is the range that production deployments demonstrate when detection architecture combines rules with behaviour-based models and thresholds are actively maintained.

Tookitaki's FinCense has reduced false positive rates by up to 50% compared to legacy rule-based systems in production deployments across APAC institutions. For a compliance team managing 400 alerts per day, a 50% reduction means approximately 200 fewer dead-end investigations daily. That capacity does not disappear — it goes to genuine risk review, EDD interviews, and STR quality.

The federated learning architecture behind FinCense addresses a detection gap that no single institution can close alone. Coordinated mule account activity typically moves between institutions — a pattern no individual bank can see in its own data. Detection models trained across a network of institutions make that cross-institution pattern visible. This is why the reduction in false positives and the improvement in genuine detection occur together: the models are trained on a broader signal set than any single institution's transaction history.

For the full vendor evaluation framework — including the specific questions to ask about false positive performance benchmarks, calibration support, and APAC regulatory alignment — see our Transaction Monitoring Software Buyer's Guide.

If your team is managing a 90%+ false positive rate and the operational picture described in this article is familiar, the starting point is a benchmarking conversation — not a full platform replacement. Book a demo to see FinCense's false positive benchmarks from comparable APAC deployments and get a calibration assessment against your current alert volumes.

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.