Covered persons in the Philippines must keep a written Money Laundering and Terrorism Financing Prevention Program (MTPP), and internal audit is one of the elements required alongside customer identification, ongoing monitoring, record keeping, reporting of covered and suspicious transactions, training, employee screening, and the appointment of a compliance officer. The duty is to set up internal controls and an internal audit programme adequate to ensure AMLA compliance happens day to day. The word doing the most work in that requirement is “independent,” and it has a definite meaning: testing carried out by the people who designed, ran, or are in charge of a control does not count as independent testing of that control, however thoroughly it’s done.
Where an institution has no separate internal audit function, independence can still be reached by having qualified staff not involved in the function being tested carry out the testing. It cannot be reached if a team reviews its own work.
Most elements of AML programmes fail obviously. A missed filing deadline is a date on a record. An incomplete customer file is a gap anyone can point to. Independent testing fails quietly, and usually produces documentation that looks entirely satisfactory.
The problem is structural, not negligence. The same team that designed the transaction monitoring rules, wrote the escalation procedures, and trained the analysts is best positioned to check whether those measures work. It is exactly for that reason they’re least able to test them independently. Whatever assumptions went into the design go into the test too. The review confirms the system does what its designers intended, which is a different question from whether it meets the regulation’s requirements.
An institution can hold a complete set of annual AML audit reports, each one signed off and noted by the board, and still never have had its programme independently tested.
Where the requirement comes from
Covered persons must keep a written MTPP approved by the board of directors or an equivalent governing body. For designated non-financial businesses and professions, AMLC guidelines require the programme to be written, risk-based, and board-approved, covering at minimum customer identification, ongoing monitoring, record retention, reporting of covered and suspicious transactions, training, employee screening, internal audit, the appointment of a compliance officer, and consideration of risks tied to new products or technologies. There’s also a certification requirement: for DNFBPs, the compliance officer must submit a sworn certification to AMLC stating that a new MTPP has been prepared, noted, and approved by the governing body.
The requirement is clear that an internal audit should exist. What it doesn’t do, and this is where institutions diverge in practice, is spell out what independence entails, how often testing must happen, or exactly what the testing must cover.
What “independent” rules out
The clearest statement of the independence principle in international AML supervision is the United States FFIEC examination manual. It isn’t Philippine law and doesn’t bind BSP-supervised institutions, but it sets out the structural logic more explicitly than most other sources, and that logic holds regardless of jurisdiction.
Independence is about involvement, not employment. Organisations without a dedicated internal audit department can meet the requirement by using qualified personnel who aren’t part of the function under review. What disqualifies someone is involvement in the activity being examined, not whether the reviewer is internal or external.
External doesn’t automatically mean independent. When outside auditors or consultants are engaged, the institution has to confirm they aren’t involved in other AML-related activities that could create a conflict, particularly training and policy development. A consultant who wrote an institution’s AML policy isn’t an independent reviewer of that policy.
The reporting line is part of the control itself. The person carrying out the testing should report directly to the board or a specific board committee. There’s a clear structural flaw if the testing reports to the head of the department being tested, no matter how competent the tester is.
Applied to a typical Philippine AML compliance setup, usually five to fifteen people carrying obligations similar to much larger organisations, this produces a real limitation. The people who understand the AML programme well enough to test it meaningfully are often the ones who built it. That limitation can be managed, but only if it’s recognised rather than ignored.
Frequency, and the absence of a fixed rule
There’s no fixed period required for independent AML testing. International practice generally lands on a review every twelve to eighteen months, plus an additional trigger: a significant change to the institution’s risk profile, systems, products, or customer base.
In practice, the trigger matters more than the timetable. An organisation that launched a new digital onboarding channel, moved into a new customer segment, or swapped its transaction monitoring platform six months after its last audit has made a material change to what’s being audited. A review that’s on schedule but predates those changes tells the board about a programme that no longer exists.
The real question a board committee faces isn’t “when was the last audit,” it’s “what has changed since then, and has anything that changed been tested?”
What testing should actually cover
Reviewing documentation to confirm it exists is one kind of independent testing. Testing whether the programme actually works is a different thing. The difference shows up in scope.
Does the institution follow its own procedures? The MTPP describes what should happen. Testing should establish whether it does, by tracing actual cases through the real workflow, not by checking that the procedure is documented.
Is the suspicious-activity detection actually adequate? The question isn’t whether alerts are produced, but whether both the alerts generated and the alerts dismissed align with the institution’s stated risk profile.
Have the detection rules been calibrated, with evidence of it? A transaction monitoring rule set that has never been reviewed since it went live is a finding, even if it produces alerts and those alerts get handled.
Are findings from earlier reviews ever closed? A finding that recurs across successive audits is more serious than a new one. It shows the testing works and the remediation doesn’t.
This is where audits most often fail to deliver value. Testing surfaces problems; those problems need remediation; remediation needs to be tracked to closure with evidence. An organisation that can produce audit reports but not the remedial-action trail has shown it has problems without proving it dealt with them.
The reconstruction problem
This failure has nothing to do with independence as governance, and everything to do with whether independent testing is even possible in practice.
An auditor checking whether transaction monitoring rules were properly governed needs to know what the rules were at a given time, who changed them, when, what the previous value was, and who approved it. An auditor examining whether an alert was properly dismissed needs the reasons recorded at the time of dismissal, not reassembled later by whoever is still around.
If the history has to be pieced together by hand, from engineering tickets, email approvals, spreadsheet change logs, and current staff’s memories, the auditor isn’t checking the institution’s records. They’re examining a version of those records the institution assembled after the fact, in response to the audit request. That’s a materially weaker exercise, an examiner reviewing the audit work will notice the difference, and it’s the point where system architecture stops being a technology issue and becomes a governance one.
Closing the gap
Fyscal Arcx is built so the record an auditor needs is available natively, not assembled on request. The Transaction Monitoring module records every rule change, threshold adjustment, and configuration modification in a native audit trail showing who made the change, when, and what the previous setting was. An auditor testing rule governance examines the actual change history rather than being given an account of it. Because the compliance team configures rules directly instead of going through a development queue, the change history also lives in one place rather than being spread across engineering tickets and release notes.
The Case Management module keeps a continuous, accumulating record for each case, including the alert, the investigation steps, the reasons behind any decision, and the approval chain. If an auditor pulls a case to see how it was handled, the information is retrievable rather than reconstructed, even after the analysts who made the decisions have left.
This doesn’t make an institution’s testing independent, since independence is a governance question about who does the review and who they report to, and no platform answers that question. What the architecture does determine is whether an independently appointed reviewer can actually test the institution’s real record.