Tipping-off prevention isn't policy —
it's seven architectural layers
Section 123 is a criminal offence, and policy alone leaves too much surface for staff to slip on. duely enforces tipping-off protection at seven different read and write paths in the system, so suspicious matter handling cannot leak through dashboards, exports, notifications, or audit trails — even when an AMLCO requests the most expansive output the platform produces.
Why this matters
Tipping off is not just a policy issue. It is a system design issue. The moment a single dashboard, list, notification, or audit query treats SMR data the same as ordinary matter data, your firm has created exposure that no policy document can fix.
duely's tipping-off prevention is built into the architecture at seven layers. Each layer defends a different read or write path, so the protection holds even when one layer is bypassed by mistake. The seven layers are listed below, followed by the operational capabilities AMLCOs use day-to-day inside the protected boundary.
What is included now
Layer 1 — SMR shadow cases as a separate aggregate
Suspicious matter data lives in its own object structure, not as a flag or column on the matter. The shadow case is invisible to non-AMLCO reads at the data layer — not by a hidden boolean, but by a different aggregate the matter views never query.
Layer 2 — AMLCO-only policy on every SMR endpoint
Every SMR API endpoint enforces the AMLCO policy at the request boundary. Non-AMLCO callers receive a forbidden response before the request reaches business logic — RBAC is the second wall, applied uniformly across every SMR write and read path.
Layer 3 — UAR redaction for staff submitters
When a staff member submits a UAR, they see their own input back — but the AMLCO's onward decision and any escalation to SMR are redacted from their view. The submitter never learns whether their flag became an SMR, removing the s123 disclosure surface.
Layer 4 — No SMR indicators on shared surfaces
Dashboards, matter lists, exports, calendar feeds, badges, stats, and notifications visible to non-AMLCO users have all SMR signals filtered out. There is no 'this matter has an SMR' tell anywhere a non-AMLCO can see — not even an oblique one like a status colour or a count.
Layer 5 — Evidence pack redaction
Neither evidence pack profile — Standard nor AMLCO-only Sensitive — ever includes SMR data. The redaction sits at the pack-generation layer, so the protection holds even when the most expansive AMLCO-only output is requested.
Layer 6 — Notification isolation (two sub-layers)
Two layers inside the notification path. The notification queue rejects SMR-restricted templates from non-AMLCO callers before they're enqueued. Beyond that, SMR-derived publishers fan out only to AMLCO recipients — even if a template were somehow pushed, it has nowhere non-AMLCO to land.
Layer 7 — Audit isolation through filtered reads
SMR events stay in the same immutable audit stream as everything else — there's no separate, sneakable audit log to be discovered. They're filtered out of non-AMLCO reads at the query layer, so the immutability story holds without leaking through audit visibility.
AMLCO Console — a dedicated workspace
Inside the protected boundary, AMLCOs sign in to a separate workspace. The Console surfaces an SMR cases list, the SMR detail workspace, the UAR review queue, and an AMLCO-targeted view of upcoming deadlines and overdue items — all isolated from the surfaces 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 — visible to AMLCOs, invisible to everyone else.
Structured narrative capture
Draft SMR narratives directly within the shadow case. All content is restricted to AMLCO-only access from creation through submission.
AUSTRAC-aligned XML export
Generate AUSTRAC-aligned XML for SMR submission directly from the shadow case — the file format AUSTRAC expects for ingestion, with no manual translation step between record and regulator.
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, RBAC, surfaces, exports, notifications, and audit
- Policy alone leaves too much surface — every read or write path needs its own enforcement
Related features
See how this capability connects to the broader compliance workflow.
AUSTRAC Reporting
SMR submission sits alongside TTR and IFTI as part of AUSTRAC reporting obligations.
Learn more →Evidence Packs
Default evidence packs never include SMR data. AMLCO can generate restricted sensitive packs.
Learn more →Audit Trail
SMR audit events stay in the same immutable stream as everything else but are filtered out of non-AMLCO reads — no separate, sneakable audit log.
Learn more →See the feature most generic AML tools do not build properly
Architecturally isolated SMR handling — because permission controls alone are not enough.