Reports to MROS, built from data you already hold
DetectX® Regulatory Reporting supports the legally compliant reporting of suspected money laundering cases to MROS, the Money Laundering Reporting Office Switzerland. It is built to the requirements of the AMLA (GwG), the AMLO (GwV) and FINMA supervisory practice.
- 1Create
- 2Finalise
- 3Archive
The DetectX® Approach
Regulatory Reporting is one module of the DetectX® platform. It reads from the options already in place, it builds on the AlertViewer, and it takes its data dictionaries from p.Lib.Admin. Reporting is the end of an investigation rather than a second system beside it.
goAML and MROS reports
The module focuses on the efficient creation, processing and management of goAML / MROS reports as required under regulatory reporting obligations.
Suspicious Activity Reports
Suspicion
Suspicious Activity Reports (SARs) are what the module is built around, and the report type every other part of it serves.
Transaction and payment detail
Detail
Transaction- and payment-related detail reports (STRs) carry the underlying movements. They are what makes a submission complete, traceable and defensible.
The instruments behind it
Regime
The AMLA (GwG), the AMLO (GwV) and FINMA supervisory practice set the requirements the module is built to meet.
From source systems to goAML XML
DetectX® Regulatory Reporting integrates relevant data from customer master data, accounts, transactions and payment systems, automatically preparing this information into regulatorily compliant goAML XML reports.
Customer, account, transaction, payment
Sources
An institution already running DetectX® reports from the customer, account, transaction and payment records its existing options hold.
goAML XML
Format
Reports are complete, consistent and generated in line with the technical requirements of Fedpol / MROS.
Extended source data
Integration
Where a report needs more than the platform holds, input data can be loaded from a data warehouse via a staging database, a datamart, and prepared there for regulatory reporting.
The MROS report repository
A generated report has somewhere to live. The repository is part of the module, and what it adds to a stored submission is version history, controlled access, and a traceable record of both.
Version control
Versions
All generated reports are stored in a structured form, under version control.
Access management
Access
Access management sits on the repository alongside version control, governing who can reach a stored report.
Full audit traceability
Audit
Version control, access management and full audit traceability support audit-ready documentation and facilitate both internal controls and external regulatory reviews.
Key Benefits and Impact
A submission nobody can reconstruct is not a defensible submission.
Regulatory Reporting builds the submission from records the platform already holds, and keeps every version of what it built. An internal control and an external regulatory review read the same record.
WHAT A GENERATED REPORT CARRIES
Why DetectX®
A submission is a claim.
The repository is the proof.
One MROS report, as the record holds it
Regulatory Reporting builds on the AlertViewer, the same workflow solution for alert and case management that the other DetectX® modules deliver into, and integrates into existing investigation processes. p.Lib.Admin maintains the data dictionaries and reference tables, so regulatory data structures are parameterised rather than rebuilt. The module was formerly Option 502.
Step 1 of 4 · Collect
The report starts from data the platform already holds
Collection is a query against records the institution already holds and already works, not a data-gathering exercise run for the report.
Recorded: the customer, account, transaction and payment data the report was built from.
Step 2 of 4 · Create
The XML is prepared, not typed
Generation is automatic. The XML is written from the data collected at the previous step, so completeness and consistency are properties of the generation rather than of a reviewer's attention.
Recorded: the report as generated, and the version it is.
Step 3 of 4 · Finalise
The submission is worked before it is closed
Review, processing and finalisation of MROS submissions are supported processes in the module, and they run on the AlertViewer alongside the case the report came out of.
Recorded: the versions the report passed through.
Step 4 of 4 · Archive
The report stays retrievable
A submission can be produced again long after it was made, with the version history that stands behind it and a record of who has been able to reach it.
Recorded: the stored report, its version history and who may reach it.
Common questions
goAML / MROS reports. In particular Suspicious Activity Reports (SARs), together with the transaction- and payment-related detail reports (STRs) needed to produce complete, traceable and defensible submissions.
The AMLA (GwG), the AMLO (GwV) and FINMA supervisory practice. The report format follows the Fedpol / MROS technical requirements.
Existing DetectX® customers report from the options they already run: those solutions act as data sources for the reporting process. Where more is needed, extended source data is supported.
It is stored in the integrated MROS report repository, under version control and access management, and stays retrievable with the version history behind it.
Regulatory Reporting · DetectX®
See a report built,
and where it is kept.
Book a demonstration on your own reporting questions: which source systems feed the report, what the goAML XML holds, and what the repository keeps once a submission is finalised.
- goAML XML
- Generated from the source data, to the Fedpol / MROS technical requirements.
- Audit-ready by default
- Version control, access management and full audit traceability on every generated report.
- One platform
- Built on the AlertViewer, with p.Lib.Admin holding the data dictionaries and reference tables.