Skip to main content
Release notes

Involved parties on a case

An officer now says how a case regards each person, company, wallet and transfer it involves, and a suspicious matter report is pre-filled from those parties. An organisation has one jurisdiction, carried onto its cases and reports, and the database itself now refuses to change a filed report.

  • Release 2026-11-01
  • 5 new
  • 3 improved
  • 2 fixed
  • 1 security

In this release

A case has always held links to people, companies, wallets and transfers, but every one of them read as "unknown" and nothing let anyone say otherwise. The suspicious matter report then asked the officer to type in what the case already knew.

Both now follow from one decision. The officer gives each party a role and a reason, the investigation proposes one where nobody has decided, and the report takes its parties, their details and their wallets from that record.

The rest of the week settles what an organisation is. It has one jurisdiction, and a report it has filed is now something the database refuses to change.

New5

Involved parties

an officer now sets a role, a role description and a reason in their own words on every person, company, wallet and transfer a case involves, while the case is open. A reason runs from 10 to 2,000 characters. Each party link is pinned to the version of that person's or company's details the officer relied on; when the record has moved on, the card says "newer version available" and the officer can move the case to the current version. The officer also picks which of the case's parties holds each wallet. Where no officer has decided, the investigation proposes a role with its reasoning, and the officer accepts it as it stands, edits it or dismisses it; a dismissal is final. Where a reason came from is recorded, so the investigation's words never read as the officer's: the card names who set the role, whether the investigation's reasoning was kept and whether it was edited, and an officer who changes only the role does not put the investigation's reasoning under their own name. Every change is an audit event, and the link's history, from creation through suggestions, role changes, moves to a newer version, holder changes and citation refreshes, is read back with who, when, before, after and the reason. An officer can correct a non-customer party's legal name from the case. On the page, an Involved parties card on the case Summary replaces the Wallets card. It lists people and companies with their role, the start of their reason, their pin and any newer-version mark, and the wallets each holds; pending suggestions sit inline with Accept, Edit and Dismiss. A party sheet has three sections, Role on this case, Details this case relies on and History on this case. Wallet and transfer sheets carry the same role, reason and history sections, and transfers stay in the Transfers card with a role badge and reason. When a party is removed from a case every wallet it held is cleared, recorded with a reason. The holder of a wallet is worked out again whenever the parties on a case change or a customer push adds or withdraws a wallet declaration, and a holder an officer chose is never replaced automatically.

A suspicious matter report pre-filled from the case

an officer filling an SMR used to re-enter what the case already knew about each party: their role, their identity details and which wallets they hold. The case's linked parties now lead the report's party picker. Each is named by its pinned version, and its role fills the party type as suspect, victim or other; an unknown role fills nothing. The pinned version's details fill the party row in AUSTRAC's own codes: names, date of birth, gender, citizenship, occupation, address (residential for a person, business then registered for a company, never a PO box), email and phone, identification, business structure, ABN, ACN, ARBN, LEI and BIC. Only verified identifications are carried; a party with only unverified identifications is filed as not verified, with no details, as AUSTRAC asks. A linked wallet names its holder and fills the account type as a digital wallet. Identity details are read through an audited path, so a read records who read which details of which party version, and the editor asks for them only when the template needs a detail the know-your-customer record cannot answer. Filing an AUSTRAC SMR gained new refusals. Submit and Approve refuse while any live party link on the case still has an unknown role, because AUSTRAC has no unknown party type; the refusal points to "other" with a description. They also refuse while a wallet the report names is not linked to the case, has no holder or has a holder that is not one of the parties the report files. Send for review shows the same issues as a note rather than a block, so a reviewer can help resolve them. A party filed with a type that differs from its case role is a warning only, and other report types are not refused.

Prior suspicious matter reports on a case's customers

an officer deciding whether to file an SMR had to search other cases by hand to learn whether the organisation had already filed on this customer. The case's Customer fact now shows a "1 prior SMR" or "N prior SMRs" badge and names the first three cases by their key. Only filed AUSTRAC SMRs on other cases that link one of this case's customers count. Only a customer counts, not a shared counterparty, and a case that links the customer as a victim does not count. An amendment is not a second report. "Filed" means approved and signed, lodged or not. "Prior" means before this case's own first filed SMR, and a case still deciding sees every SMR filed so far.

An unusual matter report carries more into a suspicious matter report

escalating an unusual matter report to an AUSTRAC SMR used to leave many answers behind. The two reports hold the same facts in different shapes, so answers are now carried by meaning rather than by a template's own identifiers: other parties join the SMR's involved parties, each party's wallet becomes a virtual asset wallet account they hold, bank details become a cheque or savings account, and "individual or business" answers "is the party an organisation?". What is left behind is what the SMR does not ask. One untranslatable cell in a table is taken out and named rather than costing the officer the whole table. The same change adds the AUSTRAC SMR clock. The suspicion is taken as formed at the case's earliest escalate or SAR decision, read from the append-only decision log, and the report is due three business days after the day the suspicion was formed, or 24 hours when the newest report in the chain answers terrorism financing. It errs early. Lodging stops the clock, and there is no clock while the newest decision closes the case as a false positive. The clock exists in the API only for now: it is not yet shown on the case header, and that display is still to come.

One jurisdiction per organisation

nothing recorded which jurisdiction an organisation, a case or a report belonged to, so every rule assumed Australia and the AUSTRAC clock ran on every case. An organisation now has one jurisdiction, chosen at onboarding straight after the organisation name, with Australia preselected and a note that once set it cannot be changed without speaking to support. It is locked after that: a new jurisdiction means a new organisation, and support changes it only on request, recorded with who asked, why and which support person made the change. Every organisation that exists today is Australian. A new case copies its organisation's jurisdiction, a report its case's and an amendment its original report's. A filed report is already frozen, so its jurisdiction can never change after filing. The case header and the report facts show the jurisdiction by name. The AUSTRAC SMR clock now runs only on Australian cases. The report template library, and the agent's list of templates it can start, put the organisation's own jurisdiction's forms first with a "Suggested" badge. General settings now separate Business details (reporting entity, branch name, address) from Regulatory, where the jurisdiction is read-only and the regulator number carries its jurisdiction's own name, such as AUSTRAC account number or goAML organisation ID. The designated services you provide are a default answer in Reporting settings, under Defaults then The matter, shown only for Australian organisations and saved with the rest of the default answers. The regulator number and the designated services are filled into a report only for an Australian organisation reporting to AUSTRAC.

Improved3

Filing pins every attachment: filing now pins every attachment on every report type to the exact stored version, file name and content hash; before this only the AUSTRAC SMR's two attachment fields were pinned. Filing refuses an attachment with no file on the case, and names it. Every upload is hashed by the server, only a hash the server computed is pinned, and an older browser-supplied hash is re-checked from storage at filing. The PDF, Word, CSV and on-screen report name the filed file with its file name and SHA-256 hash. A filed report lists its filed attachments and downloads the pinned version; that download is audited and linked to both the report and the case, and a download whose filed version is no longer in storage is refused with a reason rather than a link that fails silently. A document a filed report pinned cannot be deleted: the case documents panel says which report holds it as evidence and links to it. An amendment pins each attachment as it stands at the amendment's filing, and the original keeps its own pins. The exported report now carries a Review row reading Approved with the approver and the time, Filed without review, In review with the reviewer's name, Draft returned from review or Draft not sent for review. A currency field without its own decimals now takes the currency's minor units, two for AUD and none for JPY, and the document prints the code after the amount.

The customers list is faster: a party record is created for every alert that names a person or company, whether or not they are a customer, so they accumulate. The customers list used to walk past every one of them, and every deleted record, to fill a page, and its total count read every party in the organisation. A new index means a page of customers comes straight off it in order, and the count is an index-only read.

Case page polish: the case record line, reading "Opened … from N alerts · Updated …", replaces the separate Created, Updated and Alerts block, and the risk score is back above the title as a word, such as "High" or "Not rated". The whole plan strip row opens the Plan tab and its button is a secondary "View plan"; plan step labels are verbs and each step's link in the rail has an icon. Search is now a single command dialog. Every case tab now sits on the same spacing, so the gaps on Summary, Explorer, Reports and the Audit log match, and empty sections on Summary no longer leave a doubled gap. The Audit log is one card with its type filter in the header and Today and Earlier as dividers. The Reports header shows the report status without a tick. Help in the sidebar now opens the Cogentic documentation in a new tab; the per-page guided tours it used to open are removed, while the sample-data walkthrough and the first-run welcome tour stay.

Fixed2

  • The author can see what the reviewer changed

    a reviewer can edit a report during review. If the review was then withdrawn, the report went back to draft with the reviewer's edits in it and nothing said what they were, so the author got back a draft someone else had changed and could not tell which answers. When a report now comes back to draft from review, sent back or withdrawn, each answer the reviewer changed is marked "Changed in review" with the old value as the hint, such as "Was: Jane" or "Was empty". Only the latest round is marked, because sending the draft again is the author accepting it as it stands, and a mark goes when its answer is back as it was sent. A Viewer reading the draft sees the marks too. Reports withdrawn before this change kept no copy, so for those the previous answer is shown as unknown rather than as nothing.

  • Withdrawing a review keeps the draft open

    withdrawing a review now keeps the author in the report as an editable draft instead of closing it. When the save before a review action fails, the dialog says why: the answers the save refused, the server's message or that the connection failed.

Security1

  • The database refuses to change a filed report

    a filed case report and a review snapshot are the compliance record: what was signed and lodged, and what a checker saw and approved. Until now each was protected in the application rather than in the store beneath it. The database itself now refuses the change, for every role. A filed report refuses every change except recording its lodgement, and refuses a move back to draft, so a filed report cannot be set back and edited afterwards. A review snapshot cannot be updated, deleted or truncated. Filing still works, and deleting a case still works.