Transaction Monitoring Philippines: From Alert to STR Filing

Transaction monitoring is the ongoing screening of customer activity against expected behaviour to detect patterns that warrant investigation. It is the detection layer that produces the alerts which may become Suspicious Transaction Reports.

One timing rule resolves most of the confusion around it: an alert is not suspicion. Per the AMLC Registration and Reporting Guidelines, where monitoring system alerts are only grounds to conduct internal analysis, the suspicious nature of the circumstances must be determined within 60 calendar days.

The next-working-day STR clock starts after that determination, not at the alert.

What Is Transaction Monitoring?

Transaction monitoring compares what a customer actually does against what their profile suggests they should be doing, continuously, after onboarding is complete.

Under AMLA and its implementing rules, the ongoing monitoring process is a distinct customer due diligence obligation rather than an optional control. Covered persons must examine the background and purpose of all complex and unusually large transactions, all unusual patterns of transactions with no apparent economic or lawful purpose, and other transactions that may be considered suspicious.

The word doing the work in that requirement is “examine”. Detection alone does not discharge it. A system that flags activity nobody investigates just builds an audit trail of things you noticed and ignored.

Rule-Based vs Behavioural Monitoring

	Rule-based	Behavioural
How it works	Fixed conditions: thresholds, velocities, counterparty lists	Compares activity against a learned baseline per customer or segment
Strength	Explainable to an examiner, deterministic	Catches patterns nobody wrote a rule for
Weakness	Evadable once the threshold is known	Harder to justify a specific alert
Failure mode	High false positives from blunt thresholds	Learns bad behaviour as normal if it starts early
Examiner view	Easy to inspect, easy to criticise as mechanical	Requires documented rationale for how it works

Most Philippine institutions run rule-based monitoring with behavioural elements layered on. That is a reasonable position, provided you document the rules and tune them periodically rather than inheriting a vendor default and leaving it alone.

Red Flag Typologies in the Philippine Market

The AMLC does not leave this to interpretation. A comprehensive list of red flag indicators is attached as Annex D to the AMLC Registration and Reporting Guidelines, and any monitoring ruleset built for Philippine operations should be mapped against it rather than against a global template.

The typologies that recur in this market specifically:

Structuring Below Thresholds

Deposits clustered just under PHP 500,000, or activity split across related accounts. Our guide to smurfing and structuring covers the pattern in depth.

Pass-through Accounts

Funds received and forwarded almost immediately, leaving negligible balance. Common in mule networks.

Profile Inconsistency

A salaried account receiving volumes that contradict the declared occupation, or a small business moving sums its stated turnover cannot support.

Remittance Layering

The Philippines receives very large inbound remittance volumes, which creates cover for illicit flows moving through legitimate corridors.

E-wallet Velocity

High-frequency, low-value movements across e-money accounts, where each individual transaction looks unremarkable and the aggregate does not.

Dormancy Followed by Burst Activity

An account inactive for months that suddenly transacts heavily, often a sign of an account sold or taken over.

Threshold Design: Why Copying Global Defaults Fails

Vendor systems ship with thresholds calibrated on other markets, and importing them produces two failures at once.

Set too high and you miss activity that is genuinely anomalous for a Philippine customer base, where median transaction values differ substantially from the markets those defaults were tuned on. Set too low and you drown the compliance team in alerts on ordinary behaviour, which is worse than it sounds because it degrades the quality of every review.

Thresholds should derive from your own institutional risk assessment and your actual customer distribution, and the reasoning should be documented. When an examiner asks why a rule fires at a particular value, the risk assessment is where the answer is supposed to live. “The vendor default” is not an answer.

One structural point specific to this market: the PHP 500,000 CTR threshold is a reporting trigger, not a monitoring threshold. Building monitoring rules at the same value tells anyone structuring around it exactly where the line sits, and catches nothing below it.

From Alert to STR: The 60-Day Window

This is the section that resolves the timing confusion most compliance teams run into, and it is worth reading closely.

Our guide to the STR sets out the filing deadline: under GoTRACS, an STR must be filed by the next working day from occurrence, where occurrence means the establishment of suspicion rather than the transaction date. Read alone, that sounds impossible to satisfy for anything a monitoring system surfaces.

The AMLC Registration and Reporting Guidelines supply the missing leg. According to the AMLC, where the circumstances for filing an STR have no corresponding transaction, or where transaction monitoring system-generated alerts are only grounds for the covered person to conduct an internal analysis, investigation, and escalation, the suspicious nature of the circumstances shall be determined within 60 calendar days.

So the chain runs in two stages:

1. Alert to determination: up to 60 calendar days to conduct internal analysis, investigation, and escalation, and to decide whether the circumstances are suspicious.
2. Determination to filing: the next working day.

Two consequences follow. An alert sitting in a queue for four months is outside the window regardless of what it eventually concludes. And once your reviewer forms the conclusion, the filing clock is measured in hours, so the escalation path must already be built rather than assembled at that point.

Worth noting for anyone benchmarking against competitor content: several widely read AML guides still state the STR deadline as five working days, which was the AMLA baseline before GoTRACS. A monitoring workflow designed around that figure is calibrated to a rule that no longer applies.

The CTR Rule That Is Stricter Than It Looks

The AMLC treats late covered transaction reporting as an absence rather than a delay. Per the AMLC, submission of CTRs beyond 12:01 a.m. of the day following the fifth working day from occurrence is considered non-submission and may be subject to administrative sanction.

That framing removes the middle ground. There is no lightly late CTR, which makes the batching and cut-off design in your reporting pipeline a compliance question rather than an operational preference.

False Positives and Alert Fatigue

Alert volume constrains every monitoring programme, and the tempting fix is the wrong one.

When queues grow, the instinct is to raise thresholds until the volume becomes manageable. That is threshold design driven by staffing rather than by risk, and it is visible in the tuning history an examiner can request.

Better levers exist. Segment rules so that thresholds reflect customer type rather than applying one value across the whole book. Suppress alerts that repeatedly close as false positives for a documented reason rather than reworking them one at a time forever. Route high-confidence patterns differently from ambiguous ones. And track closure reasons, because a rule producing thousands of alerts that all close identically is not detecting anything.

The 60-day determination window is generous enough to permit proper investigation and short enough that a backlog becomes a compliance exposure rather than an operational annoyance.

Why Monitoring Depends on Onboarding Data Quality

Every monitoring rule compares activity against an expectation, and that expectation was set during customer due diligence. Occupation, declared income, business type, expected transaction volume, geography.

Where that profile is thin or unverified, profile-inconsistency rules cannot fire, because no reliable baseline exists to deviate from. The system runs, produces alerts on crude thresholds only, and reports clean on everything that requires context.

The failure is quiet, which is what makes it dangerous. Nothing errors. Coverage simply narrows to whichever rules work without customer context.

To be precise about scope: Verihubs is not a transaction monitoring system. What Verihubs eKYC supplies is the verified identity and profile data at onboarding that monitoring baselines against, across 15+ Philippine government ID types with biometric liveness and deepfake detection.

What AMLC Examiners Check

Examination focuses less on the system and more on what happened around it.

Expect scrutiny on whether rules are documented and justified by the institutional risk assessment; whether thresholds have been tuned and the tuning recorded; whether alerts were investigated within the determination window; whether decisions not to file were documented, since that is required as much as filings are; whether STRs were complete, accurate, and timely; and whether the reporting chain named in the AML compliance program matches what the alert history shows actually happened.

That last comparison is the one institutions underestimate. The MTPP describes a process, and the alert queue records the real one. Where they diverge, the written program becomes evidence against the institution rather than for it.

Frequently Asked Questions About Transaction Monitoring

Is a transaction monitoring alert the same as suspicion?

No. Per the AMLC Registration and Reporting Guidelines, where system-generated alerts are only grounds for internal analysis, investigation, and escalation, the suspicious nature of the circumstances must be determined within 60 calendar days. Suspicion is the conclusion of that review, not the alert itself.

How long do we have to file an STR after an alert?

Two stages apply. Up to 60 calendar days from the alert to determine whether the circumstances are suspicious, then the next working day from that determination to file the STR under GoTRACS. Guides stating a flat five-working-day STR deadline are citing the pre-GoTRACS baseline.

Where can we find the official Philippine red flag list?

A comprehensive list of red flag indicators is attached as Annex D to the AMLC Registration and Reporting Guidelines. Monitoring rulesets for Philippine operations should be mapped against it rather than against a global vendor template.

Can we set monitoring thresholds at PHP 500,000 to match the CTR rule?

That would be a design error. PHP 500,000 is a covered transaction reporting trigger, not a monitoring threshold. Aligning monitoring to it catches nothing below the line and signals exactly where the line sits. Thresholds should derive from your own institutional risk assessment and customer distribution, with the reasoning documented.

What happens if a CTR is filed late?

Per the AMLC, submission beyond 12:01 a.m. of the day following the fifth working day from occurrence is considered non-submission of the CTR and may be subject to administrative sanction. There is no partial credit for a late filing.

Do we need to document alerts we decide not to escalate?

Yes. The reporting chain runs from the triggering event to either the filing of an STR or the documentation of a decision not to file. An alert closed without a recorded reason is a gap an examination can surface.

Detection Is the Easy Half

Buying a monitoring system is straightforward. What examinations actually probe is everything the system does not do by itself: why the thresholds sit where they do, whether alerts were investigated inside the determination window, whether closures were reasoned, and whether the written program matches the alert history.

Underneath all of it sits the customer profile, because a monitoring rule can only measure deviation from something. Where onboarding produced a thin or unverified profile, the most valuable rules cannot fire at all, and the system reports clean on exactly the customers who warranted context.

Verihubs eKYC API establishes that profile at account opening for Philippine covered persons, with government ID verification, PhilSys authentication, biometric liveness, and deepfake detection.

Talk to the Verihubs team about the onboarding data your monitoring rules depend on.