Regulatory reporting automation uses a case record to prepare, check and track AML filings, so that suspicious and covered transaction reports reach the regulator complete and on time. It does not decide whether a transaction is suspicious. That judgement stays with a person, and the automation's job is to protect the clock that starts once it is made.
This guide covers the filing clocks and requirements in AMLC's GoTRACS issuance, and the other reporting duties that run beside them. It does not cover system validation or rejection rules, which the sources reviewed do not set out, so check those with the AMLC directly.
It is written for heads of AML and reporting officers who run lean teams and want to know what is worth automating, what should stay manual, and what an examiner will ask to see.
What is regulatory reporting automation in AML?
It is the use of software to carry data from an investigation into a regulator-ready filing, and to time every step against the deadline.
In practice that means four jobs: pulling customer, transaction and case data into the report, checking that it is complete, starting and tracking the deadline, and keeping a record of what was filed and when. Automated regulatory reporting works only when the case record is already accurate, because a filing built from poor data inherits the problem faster. Our guide to filing a BSP-ready STR covers what the report itself should contain.
Which clock applies to which filing?
Each filing has its own trigger and deadline, and mixing them up is the most common source of late reports.
| Filing | Trigger | Deadline |
|---|---|---|
| Suspicious transaction report (STR) | Establishment or determination of suspicion | The next working day from occurrence |
| Covered transaction report (CTR) | A covered transaction | Five working days from occurrence |
| ML/TF/PF risk event report | Knowledge or discovery of a qualifying event | Within 24 hours |
| Freeze return (sanctions) | A freeze on a target match | Within 24 hours from effecting the freeze |
The first two come from AMLC's GoTRACS issuance, Regulatory Issuance No. 2 of 2024. ACCRALAW's summary states that an STR is due "within the next working day from occurrence" and defines occurrence as the establishment of suspicion or the determination of the suspicious nature of the transaction. It also states that a CTR is due within five working days, and that submissions beyond the prescribed periods are non-compliance. BusinessWorld's report confirms the five-working-day CTR window and that CTRs go through the AMLC's File Transfer and Reporting Facility. We explain why the STR clock catches teams out in our piece on the STR filing window.
The risk event report comes from BSP Circular 1193, which requires submission within 24 hours from the date of knowledge or discovery. The freeze return comes from the AMLC's 2021 sanctions guidelines. Terminology differs from US practice, which our guide to SAR versus STR sets out, so a workflow imported from a US process will count from the wrong date.
Where do AML filings go wrong?
They go wrong in four places: the clock, the data, the narrative and the change of format.
The clock. Teams count from the transaction date when the STR window runs from determination. A report can be filed quickly after the transaction and still be late if the determination date was never recorded.
The data. Customer details sit in one system, transaction data in another and investigation notes in a third. Re-keying them into a report invites omissions, and the filing has to be complete, accurate and timely, as the GoTRACS issuance requires.
The narrative. A report that restates the alert without explaining why the activity departs from the customer's profile is hard for the AMLC to use. It is also the part that takes an analyst the longest to write.
The format. ACCRALAW notes that the issuance phases in a new reporting format and a requirement to upload KYC documents and a beneficial owner Excel template for STRs on juridical persons, due between one and three years after effectivity. Check which of these have taken effect, because a hard-coded export breaks when the format changes.
What should be automated, and what should stay human?
Automate the assembly, the checking and the timing, and keep the decision to report with a person.
| Step | Automate | Keep human |
|---|---|---|
| Deadline | Start the timer from the recorded determination, and escalate before the window closes | Record the determination and the reasoning |
| Data | Pre-populate the report from customer due diligence, transaction and case data | Confirm the data is right |
| Completeness | Block submission when mandatory fields or attachments are missing | Resolve gaps with the business |
| Narrative | Draft from the case content for review | Edit, approve and own the narrative |
| Format | Export in the structure the AMLC requires, and update it when it changes | Test after each format change |
| Record | Log who prepared, reviewed and filed, with times | Review the log for patterns |
The test for any automation is whether a reporting officer can explain to an examiner what the system did and what the person decided. FATF Recommendation 20 requires suspicions to be reported promptly to the financial intelligence unit, and automation helps with the word "promptly" without changing who is accountable.
How do you measure reporting quality?
Track a small set of measures that show whether the process is on time, complete and consistent.
- Time from determination of suspicion to filing, against the window.
- The share of filings complete at first submission.
- Late filings by cause: clock, data, narrative or format.
- Rework or amendment rate after submission.
- Share of narratives that pass a quality review for specificity.
- Share of filings with a complete timestamp trail.
None of these needs an outside benchmark. Report them monthly to the forum that reviews independent testing results, and expect them to matter for the 2027 evaluation, where assessors look at effectiveness evidence.
What will an examiner ask about filings?
Expect three questions: when was suspicion determined, when was the report filed, and was that within the window.
BSP's Memorandum M-2023-013, the guidance paper on an effective AML/CTPF transaction monitoring system, covers suspicious transaction reporting and post-STR monitoring alongside alert and case management. The answer to each question should come from a system record, because a spreadsheet maintained by one person is hard to defend. A reviewer who picks any filing should be able to trace it back to the alert, the case, the determination and the approver. For the wider supervisory context, see our BSP Circular 950 compliance guide.
How does Fyscal ARCX support regulatory reporting?
Fyscal ARCX Regulatory Reporting works from the case record, so the filing and the investigation share one source. A guided six-step workflow pre-populates institutional and case information and tracks the applicable filing deadline, with an escalation alert to the responsible officer before the window closes. The AI layer drafts the STR narrative from the case content for the analyst to edit and approve, and CTR fields are pre-populated from the customer due diligence, transaction and case data. Reports export in the GoTRACS file format, and every report sits in a searchable filing record by case title, case ID or STR ID.
If you want to see how a closed case becomes a tracked, reviewed filing in one workflow, book a walkthrough of Fyscal ARCX and bring a recent filing to trace end to end. For a vendor checklist that covers reporting alongside other modules, see our AML software buyer's guide.