The Anti-Financial Account Scamming Act moved fraud monitoring from a best-practice a Philippine bank should have to an obligation it mustdemonstrate. For the engineering teams inside BSP-supervised institutions, that changes the question from “is our fraud detection good enough” to “can we prove, to the regulator, that it does specific things in real time.” This note is about what those specific things are.

AFASA (Republic Act No. 12010) gives the BSP and law enforcement real teeth against the account-takeover and mule-account economy that has grown alongside Philippine digital banking. Most of the public coverage focuses on the powers — account freezing, information sharing, penalties. The part that lands on an engineering team is quieter: the law and its implementing rules expect supervised institutions to detect and act on suspicious activity as it happens, not in a batch report the next morning. That is an architecture requirement, and the institutions working toward the 2026 compliance horizon are discovering it is not a feature you switch on.

Who is actually in scope

The perimeter is wider than the big banks. AFASA reaches the full set of BSP-supervised financial institutions and operators of payment systems — which in the Philippine market means, at minimum:

The universal and commercial banks — BDO, BPI, Metrobank and their peers — with the largest account bases and the most account-takeover exposure.
The digital banks and e-money issuers — Maya, Tonik, GoTyme, UnionDigital and the rest — where onboarding is fast, the customer is remote, and the mule-account problem is most acute.
The rural and thrift banks and the wider set of e-wallets and payment operators, who carry the same obligation with a fraction of the engineering bench to meet it.

That last group is where the real engineering pressure sits. A tier-one bank can absorb an eight-figure fraud-platform contract. A rural bank or a mid-size e-wallet has the same regulatory obligation and nothing like the same budget — which is exactly the gap this note is written for.

What “real-time fraud monitoring” means at the engineering level

Strip away the procurement language and the obligation resolves into four functions that have to run on the transaction path — synchronously enough to hold, challenge, or block a transfer before the money leaves — not in an overnight job.

1. Behavioural analytics

A model of how each account normally behaves — typical counterparties, amounts, times, devices, and velocity — so that a deviation (a dormant account suddenly sweeping funds to three new beneficiaries at 2am) raises a score the moment it happens. The engineering substance is a feature store fed by the transaction stream, a scoring service on the authorisation path, and a feedback loop that learns from confirmed fraud. The hard part is latency: the score has to return inside the transaction window, which rules out a lot of architectures that would be fine for reporting.

2. Device and session fingerprinting

Tying activity to a device and session signature so that a known-good customer on a new, unrecognised device — the classic account-takeover signal — is treated differently from the same customer on their usual phone. This is data you have to capture at the edge, on the app and web clients, and carry through to the scoring decision.

3. Intercept-resistant authentication

The OTP-over-SMS model that most Philippine institutions still lean on is precisely what the scamming economy has learned to defeat, through social-engineering and SIM-swap. AFASA-era controls push toward MFA that resists interception — app-based or cryptographic factors bound to the device — for high-risk actions. That is an authentication-architecture change, not a configuration toggle, and it touches every channel.

4. Blacklist and mule-account screening

Screening beneficiaries and accounts against shared watchlists and institution-level blacklists, so that a transfer to a known mule account is caught at the point of transfer and the relationship can be reported. The engineering challenge is keeping the screening current and fast, and capturing an audit trail of every decision the regulator can later inspect.

Underneath all four sits the requirement that makes this a system and not a product: an audit-grade record of every score, every challenge, every block, and every report — tamper-evident, queryable on demand, and retained. The monitoring is only half the obligation; being able to prove the monitoring ran is the other half.

Build versus buy: what the platforms cost in pesos

The incumbent answer is a fraud platform — NICE Actimize, Featurespace, SAS — engineered for global tier-one banks and priced for them. In the Philippine market those platforms arrive as multi-year enterprise contracts: a licence or subscription that scales with transaction volume, plus an implementation engagement to integrate the platform with your core, your channels, and your data — frequently landing in the tens of millions of pesos before the first alert fires, and carrying an annual cost that does not stop. For a tier-one bank that needs a globally-validated model and a vendor the regulator already recognises, that is a defensible decision.

For a digital bank, a rural bank, or an e-wallet operating at Philippine scale on Philippine fraud patterns, the math is harder to justify. The global model is trained on data that is not yours, the per-transaction pricing compounds as you grow, and the integration work — which is most of the cost and most of the risk — is the same whether the engine is bought or built. The capability is real and required; the question is whether it has to arrive as an eight-figure foreign platform.

What building it actually involves

A custom AFASA-era monitoring layer, built on your own cloud account and owned by your institution, is an engineering project with a recognisable shape: a streaming pipeline off your transaction system, a feature store and scoring service on the authorisation path, device-signal capture at the client edge, a screening service against current watchlists, and the tamper-evident audit log that turns the whole thing from a control into evidence. Trained on your own transaction history and your own confirmed fraud, a model built for Philippine behaviour can outperform a generic global one on exactly the patterns that matter locally — because it is learning from your customers, not someone else’s.

This is the same risk-scoring engineering we describe elsewhere, applied to the fraud-monitoring case, and it sits on top of the cloud posture a supervised institution already has to maintain — which is the subject of our note on BSP Circular 982. The two obligations overlap: the monitoring has to run inside a cloud setup that already satisfies data residency, audit trail, and encryption-at-rest, and the AFASA layer is the real-time control that sits on that foundation.

What this means if you are considering building fraud monitoring in PH

Three honest points to close on. First, the capability is not optional and the timeline is not generous — if your institution is BSP-supervised, the real-time controls are a question of when and how, not whether. Second, the global platforms are real and right for the institutions they were built for; naming their cost is not an argument that they are wrong, only that they are aimed at a buyer larger than most of the Philippine perimeter. Third, a custom build is a serious engineering undertaking — it is not a weekend project, and anyone who tells you otherwise is selling something — but for an institution at Philippine scale, on Philippine fraud patterns, with a budget that does not stretch to a foreign platform, it is the option that is rarely put on the table.

Orkids routes top-tier banks through certified channel partners and is direct about that boundary. Where this note is genuinely useful is for the digital bank, the rural bank, or the e-wallet that has the obligation and not the platform budget — the conversation about scoping a build is one we are glad to have on its engineering merits.