AFASA Compliance for Philippine Banks: What RA12010 Requires From Fraud Controls

Listen To Our Podcast🎧

• 2:28

AFASA Compliance for Philippine Banks: What RA 12010 Requires From Your Fraud Controls

Secure. Automate. – The FluxForce Podcast

What does RA 12010 require from a bank's fraud controls?

Philippine banks should treat Republic Act No. 12010, the Anti-Financial Account Scamming Act (AFASA), as an operating-control mandate, not a policy update. The law connects fraud prevention to account protection, disputed-fund handling and cross-institution verification (Republic Act No. 12010; BSP Circular No. 1213, corrected copy; BSP Circular No. 1215).

It also creates an inquiry path for evidence that the Bangko Sentral ng Pilipinas (BSP) may inspect.(BSP Circular No. 1214)

The practical test is simple: can your bank detect a suspicious transfer, hold the disputed funds within the permitted process, trace the transaction chain, explain the action to the customer, preserve the evidence and put each consequential decision in front of an accountable person? A fraud score by itself does not satisfy that test.

Request an AFASA fraud-control workflow review

and bring one anonymized disputed-transfer workflow. The review can map the evidence, handoffs and human decisions that a Fraud Prevention workflow would need to support. It cannot provide legal advice or certify AFASA compliance.

Request a FluxForce demo

What will you learn?

• What RA 12010 changes for fraud-control owners at Philippine banks
• How BSP Circulars 1213, 1214 and 1215 turn the law into operating requirements
• Which controls belong in prevention, detection, response and evidence
• How to separate automated actions from decisions that need accountable human review
• What to test before declaring an AFASA program ready

The AFASA control loop

A useful AFASA operating model has six connected stages:

1. Protect the account. Reduce the chance that credentials, devices or beneficiary setup can be abused.
2. Detect the event. Monitor digital transactions in real time and identify activity that may be disputed or fraudulent.
3. Contain the funds. Apply the bank's approved holding process when the legal and regulatory conditions are met.
4. Trace and verify. Follow the funds across originating, receiving and subsequent institutions while collecting evidence from the customer and participating institutions.
5. Decide and communicate. Give the authorized bank officer enough evidence to continue, extend, release or escalate the hold, then notify the affected customer.
6. Prove the case. Preserve transaction logs, alerts, communications, approvals and final outcomes for supervisory review.

This is an editorial control model, not a description of a regulator-approved technology architecture. Each bank still needs legal and compliance review against its products, BSP classification and approved policies.

What does RA 12010 require from a bank's fraud controls?

RA 12010 requires institutions to protect access to client financial accounts with adequate risk-management systems and controls. Those controls must be proportionate to the nature, size and complexity of the institution's operations. The Act also provides for restitution when an institution fails to employ adequate controls or the required degree of diligence. (BSP AFASA booklet with implementing rules)

BSP Circular 1213 then sets the broader fraud-control standard. It calls for automated, real-time monitoring that can identify and block disputed, suspicious or fraudulent online transactions. It also requires controls proportionate to the complexity and value of the bank's electronic products and services.(BSP Circular No. 1213, corrected copy) Circular 1213 gave covered institutions one year from its effective date to comply, so that transition period had elapsed by October 3, 2026.(BSP Circular No. 1213, corrected copy)

Circular 1215 adds the coordinated response layer. It defines a fraud management system as automated, real-time monitoring and detection used to identify and block disputed or suspicious online transactions. It also sets procedures for tracing, temporary holding and coordinated verification of disputed funds.(BSP Circular No. 1215)

The result is a joined control obligation. Prevention, monitoring, case handling and interbank response cannot operate as separate projects with different evidence trails.

The legal requirement and the operating standard are different

Compliance teams should keep four categories separate.

• Protect the account, detect the event and contain disputed funds under approved rules.
• Trace and verify the transaction, route consequential decisions to an authorized person, then preserve the evidence.

Source context: https://www.bsp.gov.ph/Regulations/Banking%20Laws/AFASA-Booklet-with-IRRs.pdf

Do not present an internal workflow choice as if RA 12010 names that exact control. And do not reduce an explicit BSP standard to optional practice.

Which prevention controls should change first?

The first priority is to close the easy paths into an account. Circular 1213 addresses authentication, account changes, device risk, customer notifications, transaction controls and record retention.(BSP Circular No. 1213, corrected copy) It also requires institutions to assess fraud risk against the products and services they offer.(BSP Circular No. 1213, corrected copy)

Start with these control questions:

• Does a high-risk profile change trigger stronger authentication and a defined protective period?
• Can the bank detect access from rooted, jailbroken or emulated devices?
• Are unauthorized scripts, bots and automated access attempts identified and constrained?
• Does the customer receive a useful transaction notification with enough detail to recognize the payee, amount, time and transaction type?
• Can the customer lock funds or set transaction limits, and do changes to those limits require strong authentication?
• Does the bank retain the transaction and security logs needed to reconstruct the event?

A prevention program should record failures as cases, not leave them as disconnected telemetry. Repeated device changes, beneficiary creation and rapid transfers may be weak signals on their own. Together, and in the context of the customer's normal activity, they may warrant review.

What must real-time fraud monitoring do?

Circular 1213 defines the expected function in operational terms: automated and real-time monitoring should identify and block disputed, suspicious or fraudulent online transactions.(BSP Circular No. 1213, corrected copy) That means the monitoring layer needs more than a dashboard.

• Signals feed fraud monitoring and the event becomes a linked evidence case.
• A fraud investigator reviews the case before an authorized action is confirmed.

Source context: https://www.bsp.gov.ph/Regulations/Banking%20Laws/AFASA-Booklet-with-IRRs.pdf

A bank should be able to show:

• which event started the review;
• which account, device, beneficiary and transaction signals were used;
• the rule, model or policy condition that fired;
• whether the system blocked, delayed, challenged or only alerted;
• who reviewed the event and what that person decided;
• what changed after the decision; and
• how the bank confirmed that the final action reached the relevant systems.

The control should also distinguish inbound and outbound risk. The originating institution knows the source customer and payment initiation.(BSP Circular No. 1215) The receiving institution knows the beneficiary account, incoming transaction pattern and subsequent movement. A useful case file keeps both perspectives visible instead of forcing an investigator to reconstruct them from email.

How does the disputed-fund holding process work?

Circular 1215 establishes an initial holding period of no more than five calendar days. It permits an extension of up to 25 additional calendar days, for a total temporary holding period of no more than 30 calendar days, unless a competent court extends it.(BSP Circular No. 1215)

• A complaint or fraud-management-system finding can trigger the initial process.
• Evidence is gathered before an authorized person decides on extension, release or the applicable legal route.

Source context: https://www.bsp.gov.ph/Regulations/Banking%20Laws/AFASA-Booklet-with-IRRs.pdf

The process begins when a complaint, fraud-management-system finding or permitted institutional trigger identifies a disputed transaction.(BSP Circular No. 1215) The originating institution verifies the transaction details, identifies the disputed funds and initiates the required hold or request across the transaction chain. The bank must keep actual receipt timestamps because timeliness affects compliance and potential liability.(BSP Circular No. 1215)

During the initial period, the source account owner may need to provide supporting documents such as a sworn complaint, affidavit or police report under the applicable protocol. An extension request must be made within the initial holding period and should state why the institution reasonably believes the transaction is likely to be disputed.(BSP Circular No. 1215)

The system can start a hold only within the bank's approved rules and authorization design. It should not make an unreviewed legal conclusion. Human reviewers need a clear queue for extension, release, escalation and customer communication decisions.

What should a coordinated verification case contain?

A coordinated verification case should follow the transaction, not the department chart. At minimum, the record should contain:

• The transfer can move from a receiving institution to a second account.
• The original alert and institution responses feed a linked case that a fraud investigator reviews.

Source context: https://www.bsp.gov.ph/Regulations/Banking%20Laws/AFASA-Booklet-with-IRRs.pdf

1. the unique transaction reference and timestamps;
2. the source and beneficiary accounts involved;
3. the disputed amount and any remaining traceable balance;
4. the complaint or fraud-monitoring trigger;
5. the alert explanation and relevant account context;
6. hold requests, acknowledgements and institution-to-institution messages;
7. customer notices and supporting documents;
8. the rationale for extension, release or escalation;
9. each reviewer, decision and timestamp; and
10. the final disposition, recovery outcome and unresolved limitation.

Circular 1214 matters here because it gives the BSP authority to investigate and inquire into financial accounts that may have been used in a prohibited act. Its inquiry process can include account records, transaction records, communications and statements from institution personnel.(BSP Circular No. 1214)

The safest design assumption is that the bank may need to explain the whole sequence later. A neat final status without the underlying evidence is not enough.

Illustrative scenario: a fast-moving mule chain

Illustrative example, not a customer result. A retail customer reports an unauthorized transfer 40 minutes after it leaves the account. The originating bank's fraud system already flagged a new device, a newly added beneficiary and an amount outside the customer's normal pattern.

The bank verifies the transaction reference and sends an initial holding request. The receiving institution finds that part of the money remains in the beneficiary account, while another part moved to a second account. Both institutions preserve timestamps and account context. The source customer provides a sworn statement during the initial holding period.

The system prepares a linked case showing the original alert, transaction chain, amount still available, customer evidence and responses from the receiving institutions. A fraud investigator reviews the evidence. An authorized officer decides whether the bank should seek an extended hold under its policy and the applicable protocol. The customer receives the required notice. No AI agent makes the legal or account decision.

The scenario shows why mule-network detection and case handling need a shared evidence trail. A model may identify a likely chain, but the bank must still verify the facts, follow the required process and keep the accountable decision visible.

Who owns each part of the AFASA architecture?

The human-control statement should be explicit in policy and system design: the bank retains authority to approve, reject, override and release. Automation may execute a pre-authorized action or prepare a recommendation, but the accountable person and the evidence behind the decision must remain visible.

What evidence will a BSP reviewer expect to reconstruct?

A defensible evidence packet should show the event from detection through closure. Keep the following together:

• Alerts, logs, hold messages, customer records and human decisions are separate evidence inputs.
• The inputs converge into one coherent exportable case record.

Source context: https://www.bsp.gov.ph/Regulations/Banking%20Laws/AFASA-Booklet-with-IRRs.pdf

• the alert and its reason codes;
• customer and account context used in the review;
• device, session, beneficiary and transaction logs;
• the exact hold or verification request;
• proof of delivery and receipt timestamps;
• customer notices and submitted documents;
• investigator notes and unresolved contradictions;
• approvals, overrides and release decisions;
• cross-institution responses;
• complaint handling and final communication; and
• retention controls and access history.

Circular 1213 requires relevant transaction logs to be protected from unauthorized manipulation and retained with adequate backup for at least five years, unless another rule or direction requires longer retention.(BSP Circular No. 1213, corrected copy) Retention alone is not the same as retrieval. Test whether a reviewer can export one coherent case without asking three teams to rebuild it.

How FluxForce fits an AFASA operating model

FluxForce's relevant solution is Fraud Prevention. The fit is an AI-agent workflow that investigates a fraud alert, gathers the available transaction and account evidence, traces related activity, prepares a case and routes the consequential decision to the bank's authorized analyst.

The company-level position is: AI agents that investigate AML, sanctions, fraud and KYC alerts and prepare the case. Your analyst makes the call, with evidence an examiner can replay. You decide how much each agent does on its own, and every one has a kill switch.

For an AFASA workflow, that means the customer configures which actions may run automatically, which need review and when the agent must stop. Aiden Flux, the Senior AI Fraud Risk Analyst, can be evaluated for evidence collection, linked-transaction review and case preparation within the Fraud Prevention workflow. The bank's analyst decides whether to continue, escalate, override or release according to approved policy.

FluxForce does not determine legal applicability, guarantee recovery, replace the BSP-mandated process or make a bank's hold decision. It must fit the bank's systems, authority matrix, information-sharing process and legal interpretation. The Philippines jurisdiction page and the AI fraud detection guide for banking provide the next internal review points.

An AFASA readiness checklist

• Map every AFASA and BSP requirement to a named policy owner.
• Inventory digital products, transaction rails and high-risk account changes.
• Test real-time detection with known fraud patterns and benign lookalikes.
• Confirm every block or hold has a recorded trigger and authority basis.
• Verify the five-day initial and 25-day extended-hold timers in the case workflow.
• Test transaction tracing across the originating, receiving and subsequent institutions.
• Review the customer notice content, delivery evidence and complaint route.
• Confirm that staff can distinguish a complaint, fraud-system finding and other permitted trigger.
• Run an extension and release exercise using the real approval matrix.
• Export one complete evidence packet for compliance review.
• Test kill-switch, override and recovery procedures for automated actions.
• Record unresolved legal, protocol and integration dependencies before launch.

Which metrics show whether the control works?

Key takeaways

• RA 12010 links fraud prevention to adequate account-protection controls and coordinated handling of disputed funds.
• Circular 1213 expects proportionate, automated and real-time fraud controls, backed by useful notifications and protected logs.
• Circular 1214 gives the BSP an inquiry route into accounts and evidence connected to prohibited acts.
• Circular 1215 turns disputed-fund handling into a timed interbank workflow with an initial five-day period and a possible 25-day extension.
• The system may detect, trace and prepare the case. The bank's authorized person owns the decision.

Conclusion

An AFASA program becomes credible when one case can move from alert to decision without missing timestamps, messages or authority. Start with a recent disputed transfer and walk it through the six-stage control loop. The gaps will be obvious.

Request an AFASA fraud-control workflow review

and bring one anonymized disputed-transfer workflow. The review can map the evidence, handoffs and human decisions that a Fraud Prevention workflow would need to support. It cannot provide legal advice or certify AFASA compliance.

Request a FluxForce demo

Frequently Asked Questions

About the author

Sahil Kataria is the Founder and CEO of FluxForce. His FluxForce author archive covers transaction monitoring, sanctions screening, model risk and operating controls for regulated financial institutions. He writes for compliance and risk teams that need clear human accountability and evidence an examiner can replay.

Related reading

• Philippines financial-crime jurisdiction guide, for local regulatory context
• Money mule networks, for transaction-chain and account-misuse patterns
• AI fraud detection in banking, for monitoring and investigation design

About the author

Sahil Kataria

Founder and CEO of FluxForce

Sahil works on secure AI and financial technology for regulated industries. His engineering background spans identity verification, payment security and compliance automation. He has led teams across Africa, the United States, Europe and India.

At FluxForce.ai, his focus is on explainable AI and auditable financial workflows. He writes for banking and compliance teams about the practical decisions behind these systems: how to assess risk, keep controls visible and introduce automation without losing accountability.

Explore Sahil Kataria's articles →