The SMR firewall: tipping-off prevention
built into the architecture
Tipping off is a criminal offence under section 123 of the AML/CTF Act, and a policy alone leaves staff too many ways to slip. duely enforces tipping-off protection on every path that reads or writes suspicious matter report (SMR) data, so it cannot leak through dashboards, exports, notifications or audit trails. That holds even for the most detailed output the AML/CTF compliance officer (AMLCO) can request.
One engagement, two views
Illustrative
- Risk rating Staff see: Medium The AMLCO sees: Medium
- Unusual activity report Staff see: Submitted The AMLCO sees: Escalated
- Suspicious matter case Staff see: Nothing shown The AMLCO sees: Open
- Lodgement deadline Staff see: Nothing shown The AMLCO sees: 3 business days
- Evidence pack Staff see: No SMR data The AMLCO sees: No SMR data
Why this matters
Tipping off is a system design problem as much as a policy one. The moment a single dashboard, list, notification, or audit query treats SMR data the same as ordinary engagement data, your firm has created exposure that no policy document can fix.
duely builds tipping-off prevention into the architecture as separate layers. Each layer protects a different read or write path, so the protection holds even if one layer is bypassed by mistake. The layers are listed below, followed by the tools AMLCOs use day to day inside the protected boundary.
What's included
SMR shadow cases stored separately
Suspicious matter data is stored in its own structure, apart from the engagement, rather than as a flag or column on it. Engagement screens never query that structure, so the shadow case is invisible at the data layer to anyone outside the AMLCO role. The protection does not depend on a hidden setting.
AMLCO-only policy on every SMR endpoint
Every SMR endpoint checks the AMLCO policy as the request arrives. Anyone outside the role is refused before the request reaches business logic. The same role check applies to every SMR read and write path.
UAR redaction for staff submitters
When a staff member submits an unusual activity report (UAR), they see their own input, but the AMLCO's decision and any escalation to an SMR are hidden from them. The submitter never learns whether their flag became an SMR, which removes that s123 disclosure risk.
No SMR indicators on shared surfaces
Every SMR signal is filtered out of the dashboards, engagement lists, exports, calendar feeds, badges, stats and notifications that non-AMLCO users see. Nothing they can see shows that an engagement has an SMR, not even an indirect sign such as a status colour or a count.
Evidence pack redaction
No evidence pack includes SMR data, whether it is the Standard pack or the AMLCO-only Sensitive pack. The redaction happens when the pack is generated, so it holds even for the most detailed AMLCO-only output.
Notification isolation
Two controls protect notifications. The queue rejects SMR-restricted templates from anyone outside the AMLCO role before they are queued. Notifications that come from SMR activity go only to AMLCO recipients, so even a template that got through would have no one else to reach.
Audit isolation through filtered reads
SMR events are written to the same immutable audit log as everything else, so there is no separate log for anyone to find. They are filtered out of non-AMLCO reads when the log is queried, which keeps the log complete without revealing SMR activity.
AMLCO Console: a dedicated workspace
AMLCOs sign in to a separate workspace inside the protected boundary. The Console holds the SMR case list, the SMR detail workspace, the UAR review queue, and the AMLCO's view of upcoming deadlines and overdue items, all separate from the screens your other staff use.
Deadline tracking inside the firewall
SMR submission deadlines (3-business-day rule, or 24 hours for terrorism financing) are tracked inside the AMLCO Console, where only AMLCOs can see them.
Structured narrative capture
Draft the SMR narrative inside the shadow case. Only the AMLCO can access it, from the first draft through to submission.
AUSTRAC SMR 3.0 XML export
Generate the SMR as AUSTRAC SMR 3.0 XML from the shadow case, validated against the AUSTRAC schema. You lodge the report with AUSTRAC as a separate step. duely does not lodge it for you.
Section 123: the tipping-off offence
- AML/CTF Act s123: tipping-off is a criminal offence carrying imprisonment
- Offence applies to anyone with knowledge of the SMR, not just the original submitter
- Prevention requires architectural separation across data, role-based access, screens, exports, notifications and audit
- Policy alone is not enough: every read or write path needs its own control
Related features
Other parts of the compliance workflow this connects to.
AUSTRAC Reporting
SMRs sit alongside threshold transaction reports (TTRs) and international funds transfer instructions (IFTIs) in your AUSTRAC reporting.
See details →Evidence Packs
No evidence pack includes SMR data, including the AMLCO-only sensitive pack.
See details →Audit Trail
SMR events are written to the same immutable audit log as everything else and filtered out of non-AMLCO reads. There is no separate log to find.
See details →See how suspicious matters are kept isolated
Architecturally isolated SMR handling, because permission controls alone are not enough.