Australia and New Zealand AML/CTF Operating Models

Australia and New Zealand are often grouped together by global banks because they are neighbouring markets with mature financial systems, close commercial links and a common FATF-based vocabulary. That grouping is useful for regional management, but it becomes dangerous if it turns into the idea that there is one "ANZ AML regime". There is not. The two countries have separate statutes, supervisors, financial intelligence arrangements, reporting forms, deadlines, sanctions frameworks and 2026 reform programmes. A bank can reuse control capabilities across both markets, but it must apply them through country-specific legal rules.

The simplest mental model is common control primitives, different statutory operating systems. Both countries expect a reporting entity to understand its money-laundering and terrorism-financing exposure, identify customers, monitor activity, keep records, escalate suspicion and support public authorities with financial intelligence. But the institutional design is different. In Australia, the Australian Transaction Reports and Analysis Centre, AUSTRAC, is both the AML/CTF regulator and the national financial intelligence unit. In New Zealand, the Department of Internal Affairs, DIA, became the sole AML/CFT supervisor on 1 July 2026, while the New Zealand Police Financial Intelligence Unit remains the FIU that receives and analyses suspicious and prescribed transaction reports.

That distinction affects real bank design. A group platform may have one case-management engine and one customer master, yet an Australian suspicion goes through Australian decision logic and AUSTRAC reporting, while a New Zealand suspicion goes through New Zealand decision logic and the Police FIU's GoAML process. A sanctions hit is another lane again: Australian sanctions are administered through the Department of Foreign Affairs and Trade and the Australian Sanctions Office, while New Zealand sanctions sit within the applicable MFAT-led sanctions framework. The AML/CFT case, FIU report and sanctions decision can be connected, but they are not interchangeable.

This chapter explains how to design that separation without building two entirely different banks.

Why 2026 is a particularly important year

A static comparison written before 2026 would now be misleading. Both jurisdictions changed materially during the year, but in different ways.

Australia's updated AML/CTF laws took effect for existing reporting entities on 31 March 2026. AUSTRAC describes the core responsibilities as continuing to include managing money-laundering and terrorism-financing risk, maintaining an effective AML/CTF program and reporting suspicious matters, while the reform changes how several obligations are implemented. The reform also widened the regulated population. Newly regulated professional sectors, including legal, accounting, conveyancing, real-estate and certain precious-metals and precious-stones businesses, entered the regime from 1 July 2026. For a bank, that expansion matters even when the bank itself was already regulated: counterparties, customers and professional intermediaries may now have their own obligations, and customer due diligence may increasingly encounter evidence produced under the reformed framework.

The Australian reform also introduced transitional mechanics. Some existing reporting entities can move eligible customers from the former applicable customer identification procedures to the new initial CDD framework over a transition period that runs to March 2029, subject to the conditions in the transitional rules. The reform also changed expectations around AML/CTF programs, compliance officers, independent evaluations and certain value-transfer or virtual-asset obligations. A global bank therefore needs effective dates and transition status in its rule inventory. It is not enough to store a single field saying "Australia AML reform implemented".

New Zealand's 2026 change was structurally different. The Anti-Money Laundering and Countering Financing of Terrorism (Supervisor, Levy, and Other Matters) Amendment Act 2026 was passed on 18 May 2026. From 1 July 2026, DIA became the sole AML/CFT supervisor for reporting entities. Before that date, AML/CFT supervision had been divided among DIA, the Financial Markets Authority and the Reserve Bank of New Zealand according to sector. The transition did not turn DIA into the FIU. Suspicious activity and prescribed transaction reporting continues to the New Zealand Police FIU through GoAML.

This is an excellent example of why a regulatory-change programme needs more than a legal summary. A policy sentence might say "New Zealand now has one supervisor." An operating model must also update supervisory ownership in regulatory inventories, portals and contacts, governance packs, issue escalation, annual reporting, assurance plans, training, data lineage and evidence repositories. At the same time, FIU reporting routes must not be redirected to DIA simply because the supervisor changed.

The two institutional models

Australia's AUSTRAC has a dual identity. As regulator, it supervises reporting entities and assesses whether they have effective systems and controls to manage AML/CTF risk and meet statutory obligations. As FIU, it receives financial reports and other data, analyses that information and disseminates intelligence to law-enforcement and national-security partners. The combined model can simplify some institutional interfaces, but a bank should still distinguish supervisory interaction from intelligence reporting internally. A regulatory examination, a suspicious matter report and a response to an intelligence request are different processes with different confidentiality, evidence and ownership needs.

New Zealand separates those functions. DIA supervises AML/CFT compliance across reporting entities from 1 July 2026. The Police FIU receives financial intelligence reports, including suspicious activity reports and prescribed transaction reports, and uses GoAML as the reporting channel. This separation should be explicit in system and procedure design. A frontline investigator should not have to infer whether a document is intended for the supervisor, the FIU or an internal governance forum from a free-text note.

Banks often make a second institutional mistake: they assume that because the FMA and RBNZ are no longer AML/CFT supervisors, they have ceased to matter. That is also wrong. Those agencies continue to have responsibilities in their wider financial-regulatory domains. The 2026 reform changes AML/CFT supervisory responsibility; it does not erase prudential, conduct, licensing or market obligations. Good governance maps obligations by legal basis and authority rather than by a loose label such as "financial crime regulator".

Scope begins with the legal entity and service

A group financial-crime policy can set minimum standards, but statutory scope attaches to legal entities, activities and services. The same banking group may operate an Australian bank, an Australian remittance or payments business, a New Zealand bank, a New Zealand non-bank financial institution and cross-border service arrangements. Each entity needs an applicability assessment.

In Australia, the regulated perimeter is built around reporting entities providing designated services under the AML/CTF framework. AUSTRAC's 2026 reform expanded and modernised that perimeter, including newly regulated professional sectors and updated virtual-asset terminology and obligations. A product catalogue should therefore map each relevant service to the legal entity providing it, customer type, channel, geography, registration or enrolment status and applicable control obligations. Product teams should not be asked simply whether a product is "AML in scope"; they should be able to show why and under which service classification.

In New Zealand, the AML/CFT Act defines reporting entities and obligations across financial institutions and other covered businesses. From 1 July 2026, DIA is the single AML/CFT supervisory point, but the bank still needs to understand the particular activities it conducts and the obligations triggered by those activities. Group design must also distinguish New Zealand reporting obligations from Australian ones when one customer relationship crosses both countries.

A practical data model therefore needs fields such as legal entity, jurisdiction, regulated-service classification, customer-booking entity, account-servicing entity, payment-processing entity and reporting owner. If those fields live only in policy documents, automated controls will eventually apply the wrong rule to the wrong event.

Risk assessment is the foundation, not a score at the end

Both operating models are risk based. That does not mean a bank calculates a customer score and considers the job finished. The risk-based approach starts at the enterprise and product level and continues through customer onboarding, transaction behaviour, trigger events, investigations and control assurance.

A bank should understand how customers, products, delivery channels, countries, payment corridors and business models expose it to money laundering, terrorism financing and, where relevant, proliferation-financing or related financial-crime risks. The institution then designs controls proportionate to those risks. A retail mortgage book, an international remittance product, a correspondent banking relationship, a corporate trade account and a virtual-asset service do not need identical control intensity because the exposure and evidence differ.

The most useful risk assessment is connected to control ownership. If a risk assessment says cross-border remittance corridors create elevated mule and scam-proceeds risk, the operating model should show which controls respond: customer due diligence, beneficiary and counterparty context, transaction monitoring, velocity analytics, enhanced review, suspicious reporting, staff training and quality assurance. If risk language never reaches scenario design or case prioritisation, it is governance theatre rather than risk management.

Australia's 2026 framework places strong emphasis on effective AML/CTF programs and independent evaluation. AUSTRAC states that independent evaluation must assess whether risks were appropriately identified, assessed, mitigated and managed, and whether policies were complied with. New Zealand similarly expects a documented risk assessment and AML/CFT programme, with DIA's current guidance forming an important supervisory reference point. The detailed legal requirements differ, but the practical principle is shared: a programme must be demonstrably connected to the risks it claims to manage.

Customer due diligence: similar purpose, different legal detail

CDD in both countries is about establishing enough reliable information to understand who the customer is, who ultimately owns or controls relevant legal persons or arrangements, what the relationship is for and whether the observed behaviour remains coherent with the bank's understanding. The legal terminology and detailed requirements differ, so a global bank should standardise the data model without pretending the local rule is identical.

At onboarding, the bank should establish the relevant identity and verification information, ownership and control, authority to act, intended products, expected activity and risk factors required by local policy and law. For corporate customers, that means more than collecting incorporation documents. The bank needs a usable representation of the customer structure: legal entities, natural-person owners or controllers where required, directors and authorised persons, business activity, expected payment corridors and material counterparties where risk justifies that depth.

New Zealand introduced a new Identity Verification Code of Practice commencing 1 July 2026. For delivery teams, a change like that should not be handled by replacing a PDF in a policy portal and leaving onboarding untouched. The bank must assess whether documentary and electronic verification journeys, exception paths, evidence retention, vendor contracts, quality checks and training remain aligned. The requirement should be traceable from source, to policy interpretation, to product requirement, to test case and finally to production evidence.

Australia's 2026 transition from eligible legacy identification procedures to the new initial CDD framework adds another design problem: two valid procedural states can exist during a transition. A bank may need to know whether a customer or customer class is being handled under a permitted transitional method, which implementation plan or policy authorises that treatment, and when the treatment must end. Hard-coding one universal "CDD complete" status discards the context that audit and remediation teams later need.

Ongoing CDD is equally important. Changes in ownership, activity, risk, products or geography can make onboarding information stale. A mature design links event-driven review and transaction-monitoring intelligence back to the customer profile. When an investigator discovers that a company has materially changed its business model, the outcome should not die in the case-management system. It should be able to trigger customer-profile remediation, risk-rating review and appropriate relationship decisions.

Monitoring should connect behaviour to the customer story

Transaction monitoring is not effective merely because a scenario generated an alert. The control needs sufficient data and context to distinguish plausible activity from behaviour that requires investigation. That means the monitoring architecture should combine transaction attributes with customer profile, account history, counterparties, channel, device or access signals where available, geography and previous investigations.

Australia and New Zealand both illustrate why country overlays matter. A single cross-border transfer can touch an Australian customer, a New Zealand beneficiary, an overseas intermediary and a separate sanctions nexus. Monitoring should not infer legal outcomes from one geography field. Instead, the event should be enriched with the legal entities involved, the payment route, party roles, customer relationships and relevant rule sets.

Instant and digital payments create a timing challenge. Scam proceeds and mule activity can move rapidly, sometimes before traditional post-event AML monitoring can respond. Fraud controls, payment controls and AML investigations therefore need information-sharing paths. The presence of fraud does not remove an AML obligation; fraud proceeds can become money-laundering activity. Equally, an AML suspicion does not automatically mean the bank should stop a payment unless the law, sanctions position, fraud controls, product terms or another authorised control provides a basis to do so. Systems should keep those decisions distinguishable.

A bank should also monitor the health of the monitoring control itself. Missing feeds, delayed files, unmapped transaction types, broken customer identifiers or rules running on incomplete data can create silent coverage gaps. Management information should therefore include data completeness and timeliness, scenario execution, backlog ageing, case quality and known control limitations rather than only alert volumes.

Suspicious reporting: do not mix Australian SMRs with New Zealand SARs

Australia uses suspicious matter reporting to AUSTRAC. Current AUSTRAC guidance states that an SMR must be submitted within 24 hours of forming the suspicion if it relates to terrorism financing, and within three business days after the day the suspicion was formed for other suspicions. Special treatment can apply where legal professional privilege is asserted over reportable information. The operational trigger is the formation of the relevant suspicion, not simply the date an automated alert first appeared.

That distinction matters for workflow timestamps. A bank should capture when the alert was generated, when it was assigned, when material evidence was obtained, when the investigator recommended suspicion and when the authorised decision-maker determined that the reporting threshold was met. A timer tied only to alert creation may be legally inaccurate; a timer tied only to final approval can be manipulated by delayed decision-making. Policy, legal interpretation and workflow design should define the suspicion-formation event clearly and preserve the evidence supporting it.

New Zealand uses suspicious activity reporting to the Police FIU. New Zealand Police guidance states that a SAR must be submitted no later than three working days after reasonable grounds for suspicion are formed. DIA guidance also emphasises that suspicious activity reporting has no monetary threshold. That is important: a small transaction, attempted activity or pattern can matter even when it falls below a prescribed transaction threshold.

Terminology is not cosmetic. New Zealand's reporting environment can distinguish suspicious activity and suspicious transactions in GoAML reporting, while public guidance commonly uses SAR as the broader concept. The bank's case system should map internal outcomes to the correct external report type rather than exposing investigators to one generic "STR/SAR/SMR" button.

Confidentiality also matters. Suspicious reports are highly sensitive, and both operating models require careful handling of information that could reveal reporting or investigative activity. Customer communications, subject access, complaint handling and frontline notes should be designed so they do not inadvertently disclose a protected report or internal suspicion. The safest architecture separates ordinary customer-service notes from restricted financial-crime case material and applies role-based access, audit logging and controlled disclosure workflows.

Prescribed and threshold reporting are different controls

A suspicious report is based on suspicion. A threshold or prescribed report is triggered by defined transaction characteristics. They can coexist.

In New Zealand, the Police FIU receives prescribed transaction reports. Public FIU guidance describes international funds transfers of NZD 1,000 or more where the transaction meets the statutory cross-border conditions, and large physical-cash transactions of NZD 10,000 or more, as prescribed transactions. If the same event is suspicious, the existence of a prescribed report does not remove the need to assess and, where required, submit the appropriate suspicious report.

In Australia, threshold transaction reporting and international transfer reporting sit within the Australian reporting architecture, alongside suspicious matter reporting. The 2026 reform introduced updated forms and transition arrangements, so banks should manage report-version and effective-date logic deliberately. A transaction reporting engine should be able to explain which rule version produced a report, which source fields populated it, whether validation errors occurred, whether resubmission happened and whether acknowledgements were received.

This is a classic BA and testing area. The requirement should not be "send required regulatory reports." It should specify trigger condition, aggregation or non-aggregation rule where applicable, report type, mandatory fields, currency and amount handling, party roles, deadline, holiday/calendar treatment, error handling, resubmission, acknowledgement, retention and operational ownership.

Payment data and the travel-rule problem

Cross-border payments are where legal rules, payment-message semantics and AML controls collide. A payment may contain an account holder, ultimate debtor or creditor, ordering institution, intermediary, beneficiary institution, remittance data, address information and references. Not every rail carries the same fields, and not every field is equally reliable.

Australia's reformed framework includes travel-rule obligations for relevant transfers of money, virtual assets or property. AUSTRAC guidance explains that businesses acting as ordering, intermediary or beneficiary institutions may need to collect, verify and share specified information. For a bank architect, that means the payment layer cannot be treated merely as a transport mechanism. The system needs to know the institution's role in the transfer, which information must accompany the transfer, what to do when required information is missing or malformed, and how exceptions are recorded.

New Zealand has its own wire-transfer and prescribed-transaction framework. The bank should not copy Australian travel-rule logic into New Zealand configuration merely because the same payment hub processes both countries. The shared hub can provide reusable capabilities: party extraction, data-quality validation, country classification, routing, screening, record retention and report generation. The country rules decide when and how those capabilities are invoked.

ISO 20022 can improve structure but does not solve poor source data. A structured debtor address that is populated with dummy or non-meaningful text is not better evidence than a clean unstructured address. Migration programmes should test semantic quality, not just XML validity. Financial-crime teams should be involved in mapping reviews because moving a party name, ultimate-party field or remittance element incorrectly can degrade screening, monitoring and FIU reporting while the payment itself still processes successfully.

Sanctions must remain a separate legal decision lane

AML/CFT and sanctions controls interact, but the legal questions are different. Suspicion asks whether activity may involve money laundering, terrorism financing, proliferation financing or other reportable concerns under the applicable framework. Sanctions asks whether a prohibition, asset-freeze rule, service restriction, trade restriction or other measure legally applies to the parties or activity.

In Australia, the Australian Sanctions Office within DFAT maintains the Consolidated List of persons, entities and vessels subject to Australian sanctions. DFAT's current guidance makes clear that the list is an Australian-law resource; it does not simply import every other country's sanctions list. Targeted financial sanctions can prohibit making assets available to listed persons or entities and can require assets owned or controlled by them to be frozen. Banks therefore need Australian sanctions logic that is related to, but distinct from, AUSTRAC AML reporting.

New Zealand implements United Nations sanctions and also has autonomous Russia sanctions under the Russia Sanctions Act and associated regulations. MFAT is the relevant governmental source for sanctions information. A suspected sanctions breach can also create suspicious-activity implications, but the bank should not collapse the outcomes. A sanctions case needs the relevant legal basis, designation, ownership/control analysis, activity restriction, licence or exemption position and operational disposition. An AML case needs the facts and reasoning relevant to suspicious reporting. One event may produce both records.

This separation is essential in cross-border group systems. A payment screened in a global hub may hit a US, EU, UK, Australian or New Zealand list. The bank must know which regimes apply to the legal entities and transaction before deciding whether to block, reject, hold, report or release. "Sanctions hit = block" is not a defensible global rule.

Data lineage is part of the control

Financial-crime controls depend on data that may come from customer onboarding, core banking, payment engines, card systems, trade-finance platforms, digital channels, screening utilities, external data providers and case-management tools. When the source-to-decision lineage is unclear, the bank cannot prove coverage.

For this regional operating model, a useful evidence map starts with six questions: which legal entity owns the customer; which system is authoritative for identity and ownership; which transaction source generated the event; which jurisdictional rule set was active at the time; which decision-maker approved the outcome; and which external authority received any required report. Those facts should be reconstructable months or years later from controlled records rather than from staff memory.

Effective dating is especially important in 2026 because both regimes changed during the year. The same customer or transaction type may have been subject to different implementation rules on 1 February, 1 April and 1 August. A rules service should therefore store validity periods, source references and change approvals. Test evidence should show boundary-date behaviour. If a production rule changed on 1 July, testing should include 30 June, 1 July and post-change scenarios.

Data quality also needs ownership. An investigator who repeatedly sees missing beneficiary addresses cannot repair a payment-originating channel by closing alerts with a note. The operating model should route recurring data defects to the product or technology owner, quantify the affected population, assess control impact and track remediation. Financial-crime operations should be a source of control intelligence, not merely a queue-clearing function.

Roles and decision rights

Strong regional governance starts by distinguishing ownership. The business owns the risk created by its customers, products and services. Financial-crime compliance sets or oversees the control framework, provides challenge and interprets policy with legal support where necessary. Operations execute customer reviews, screening or investigation activities according to defined authority. Technology maintains the platforms and data pipelines. Data owners are accountable for source quality. Internal audit provides independent assurance.

Australia's framework specifically emphasises the AML/CTF compliance officer and independent evaluation. New Zealand reporting entities similarly need clear AML/CFT compliance responsibilities and a programme capable of supervisory review. Group organisations may use different job titles, but the legal entity still needs accountable local ownership. A regional head cannot make local statutory accountability disappear by centralising processing offshore.

Decision rights should be explicit for high-impact outcomes: forming and approving suspicion, filing an external report, restricting or exiting a customer, accepting an exception, overriding a screening disposition, applying a sanctions freeze, releasing a held payment, approving a transitional implementation plan and closing a material control issue. Each decision should identify the authorised role, required evidence and escalation path.

Governance forums should see outcome measures, not just production counts. Useful management information includes overdue regulatory reports, alert and case ageing, unresolved sanctions holds, high-risk customer-review backlog, data-quality defects, report-rejection rates, independent-evaluation findings, repeat QA errors, transition milestones and remediation status. A fall in alert volume can be good tuning or broken detection; governance needs enough context to tell the difference.

Customer impact and proportionality

AML/CFT controls can harm legitimate customers when poorly designed. Requests for source information can be repetitive, account restrictions can interrupt salaries or business payments, delayed onboarding can affect property transactions, and poorly explained investigations can damage trust. A risk-based model should reduce unnecessary friction while preserving evidence and escalation where risk is real.

The operating model should distinguish legal requirements from bank risk appetite. A bank may decide not to offer a certain product or customer segment even where the law would permit it, but customer communications and governance should not describe that commercial decision as a statutory prohibition. Equally, a relationship manager should not waive a legal or policy requirement because a customer is commercially important.

Vulnerable customers require particular care. Fraud victims may also appear in AML monitoring because their accounts receive or send unusual payments. A mule may be knowingly complicit, coerced, deceived or otherwise vulnerable. The investigation should establish facts without assuming intent from a pattern alone. Where the bank can lawfully explain a request or delay, communications should be clear and proportionate; where disclosure restrictions apply, staff need approved wording and escalation support.

Common failure modes

The first failure is treating Australia and New Zealand as one ruleset. This leads to the wrong authority, report type, threshold, deadline or supervisory reference being applied. The cure is an effective-dated jurisdiction and legal-entity rules service, not more training slides.

The second failure is confusing regulator and FIU responsibilities. Australia's combined AUSTRAC model can make teams assume New Zealand is the same. After July 2026, DIA is New Zealand's sole AML/CFT supervisor, but Police FIU reporting through GoAML remains separate. Contact directories, workflow routing and training should make that obvious.

The third failure is failing to manage transition. A reform programme may declare completion because policies were approved, while customer journeys, reports, monitoring data, vendor interfaces or independent evaluation plans still follow the old framework. Regulatory change should not close until requirements, technology, operations, training, controls and evidence all agree.

The fourth failure is poor payment semantics. If a bank cannot distinguish ordering customer, ultimate party, intermediary, beneficiary and institution roles, it may screen the wrong field or populate a regulatory report inaccurately. ISO 20022 implementation should be used to improve semantic clarity, not merely message syntax.

The fifth failure is control fragmentation. Fraud finds a mule, AML investigates a separate alert, sanctions investigates a name hit, and customer due diligence separately notices an ownership change, yet none of the teams sees the combined picture. Shared identifiers and controlled intelligence hand-offs are necessary without weakening access restrictions or tipping-off protections.

The sixth failure is measuring throughput rather than effectiveness. Clearing 10,000 alerts quickly is not a success if the data feed omitted a major payment channel. An operating model should measure whether material risk is detected, decisions are timely and defensible, regulatory reports are complete, and identified weaknesses are actually fixed.

What a business analyst or architect should capture

A BA working on an Australia-New Zealand financial-crime capability should be able to trace every important requirement to a jurisdiction, legal entity, source and effective date. Requirements should specify the event that triggers the control, the data required, the decision owner, the expected output, the deadline and the exception path. Statements such as "system should support AML compliance" are not testable enough.

For customer controls, model identity, ownership, authority, expected activity, risk rating, review status and evidence provenance. For payments, preserve party roles, account identifiers, institutions, geography, amount/currency, remittance information and end-to-end references. For cases, preserve trigger, chronology, linked alerts, customer context, evidence, decision reasoning, approver and external report references. For reporting, preserve schema version, rule version, generated payload, validation outcome, submission time, acknowledgement and resubmission history.

Architecture should separate reusable capabilities from country policy. Screening engines, monitoring platforms, case management, workflow, document storage and reporting gateways can be shared. The rules that determine applicability, deadlines, mandatory fields, escalation and disposition should be versioned by jurisdiction and legal entity. That design reduces duplication without hiding legal differences.

Testing should include more than happy paths. Use Australian and New Zealand customers with similar names but different legal entities; cross-border payments in both directions; missing party data; a transaction that triggers a prescribed or threshold report but no suspicion; a suspicious case below any monetary reporting threshold; a sanctions hit that is not a true match; a true sanctions case that also creates suspicion; a report rejected by the external portal; an outage close to a filing deadline; and a rule change that takes effect at midnight on a defined date.

Practical case: one regional customer, two legal systems

Consider a corporate group headquartered in New Zealand with an Australian subsidiary. The New Zealand parent holds an operating account with the bank's New Zealand entity. The Australian subsidiary has an Australian account used for local supplier payments. Both companies share directors and a treasury team. The group begins making frequent payments to a newly added overseas supplier through the Australian account, while the New Zealand account receives large credits from an unrelated company and transfers part of the value to Australia.

A weak regional model produces two isolated alerts. The Australian team sees outbound payments and asks only whether the Australian customer is suspicious. The New Zealand team sees incoming credits and closes them because the individual transactions fit existing thresholds. Neither sees the ownership relationship or the cross-border value chain.

A stronger model links the customers through the group identifier while respecting access controls. Investigators can see that expected activity changed in both countries. Australian monitoring identifies the new supplier, payment corridor and rapid onward transfers. New Zealand monitoring identifies the unexplained third-party credits and their relationship to the Australian funding pattern. The case team reviews business purpose, source of funds, ownership, invoices and payment history rather than assuming that the corporate relationship itself is suspicious.

Suppose the evidence eventually gives the Australian team reasonable grounds for a reportable suspicion and the New Zealand team independently reaches the New Zealand threshold. Each legal entity follows its own reporting process. Australia submits the appropriate SMR to AUSTRAC within the applicable timeframe. New Zealand submits the appropriate suspicious activity or transaction report to the Police FIU through GoAML within its applicable timeframe. The reports can reference related facts as lawfully permitted, but one filing does not substitute for the other.

Now add a sanctions screening match on an overseas supplier director. The bank pauses the relevant decision path and resolves identity, ownership/control and legal applicability under the sanctions regimes that apply to the transaction and legal entities. The sanctions conclusion is recorded separately from the AML suspicion. If the match is false, that does not erase the AML concerns. If it is true, the required sanctions action does not automatically satisfy suspicious-reporting duties. The case demonstrates why shared evidence and separate legal decisions are both necessary.

For technology teams, the most important artefact from this case is the event trail. A reviewer should be able to reconstruct customer profiles, transaction links, screening results, monitoring alerts, evidence requests, investigator reasoning, decision timestamps, external-report references and any customer action. That is what turns a regional platform into a defensible operating model.

Key takeaways

Australia and New Zealand can share a strong regional control architecture, but they should never be configured as one legal regime. Australia uses AUSTRAC as both AML/CTF regulator and FIU. New Zealand, from 1 July 2026, uses DIA as the sole AML/CFT supervisor while the Police FIU continues to receive financial intelligence through GoAML. Both countries changed materially in 2026, so effective dates and transition states are essential.

The most reliable design separates reusable capabilities from local legal rules. Customer data, payment enrichment, screening, monitoring, case management and evidence storage can be common. Applicability, reporting, deadlines, sanctions, regulatory ownership and transition logic remain jurisdiction specific. When those distinctions are visible in data, workflow and governance, a bank can gain regional efficiency without sacrificing legal accuracy.

Engineering a shared platform with two legal decision models

A regional bank can reduce duplication by sharing customer-data services, investigation tools and reporting infrastructure. That architectural efficiency becomes a weakness when shared software silently turns different legal obligations into one rule. The useful unit of design is therefore a versioned country-control profile: a documented set of applicability decisions, data requirements, authorities, timing rules and evidence expectations that can be applied consistently without erasing local accountability.

This deep dive develops a fictional implementation for a banking group with Australian and New Zealand entities. Its records, test cases and operational states are proposed design choices. They are not additional statutory requirements, prescribed report layouts or advice about a particular customer's legal position. The purpose is to show how the chapter's regulatory distinctions become requirements that developers, testers, operations teams and compliance officers can actually use.

Begin with three separate inventories

The first inventory records the legal perimeter. For each entity and service, it identifies the jurisdiction, basis of regulation, relevant obligation, authority and effective period. The second records implementation: which system, process, team and configuration implement that obligation. The third records evidence: what a reviewer should be able to retrieve to demonstrate that the control operated for a particular customer, transaction or reporting decision.

Keeping these inventories separate prevents a familiar mistake. A system release can be complete while a legal obligation remains only partly implemented; a policy can be approved while the operational evidence is still unavailable; and a control can work today without the bank being able to explain which version applied last month. A traceable relationship between the three inventories makes those gaps visible.

An obligation entry should not merely say “AML reporting”. It should distinguish the type of report, the entity responsible, the decision that triggers it and the destination. A system entry should not merely name the regional case tool. It should identify the profile and interface through which the local obligation is executed. An evidence entry should not say “available in logs” unless the owner has demonstrated a reliable way to retrieve those logs with the necessary business context.

Convert Australian transition rules into controlled applicability

AUSTRAC's current transitional guidance distinguishes initial customer due diligence from ongoing CDD. Eligible reporting entities may apply the former identification procedures to specified customer classes under documented transitional policies, with transition dates and governance. The guidance does not provide a general suspension of ongoing CDD. This distinction should be checked against the entity's actual eligibility and approved policy rather than inferred from a customer's account-opening date. Primary source: AUSTRAC's 2026 transitional rules guidance.

In the fictional implementation, the applicability service therefore stores the entity, designated-service context, approved customer class, applicable initial-identification method, effective date and policy version. It does not use one flag called “old customer”. An account opened before a project milestone is not, by itself, proof that a particular transitional treatment is permitted. The compliance-approved classification must be visible in the decision record.

A customer-class change deserves explicit treatment. If an entity changes its approved transitional policy, the release should identify which customers are affected and when the new classification applies. The bank should retain the earlier decision and the facts used at that time. Otherwise, a later reviewer may see today's classification and incorrectly conclude that a historical onboarding decision used the wrong rules.

The same design should avoid treating the initial-identification method as the entire customer-control state. Monitoring, customer-risk review and escalation continue through their own applicable controls. A customer whose initial identification remains under an eligible transitional arrangement can still present new information or behaviour requiring action. Conversely, migration to a new initial CDD method does not establish that all ongoing monitoring issues have been resolved.

Update New Zealand supervision without misrouting intelligence

DIA became New Zealand's sole AML/CFT supervisor on 1 July 2026. The New Zealand Police FIU remains the relevant financial-intelligence reporting destination, including through GoAML. The platform should represent these as separate relationships. Primary sources: DIA's 1 July 2026 guidance announcement and New Zealand Police's GoAML guidance.

A migration requirement that simply replaces every historical supervisor name with DIA would be unsafe. Some records describe historical supervision; others support an active supervisory interaction; still others concern FIU reporting or a different regulatory responsibility. The implementation needs to update current routing where appropriate while preserving historical context and unrelated authority relationships.

For example, the group might change the owner of a current AML/CFT supervisory-return workflow, revise its contact register and update the relevant governance pack. It should not redirect a suspicious activity report to the supervisor merely because both processes use the same document-management platform. Nor should an old examination record be rewritten to suggest that a different authority conducted it. Current routing and historical evidence are distinct data concerns.

Specify the minimum decision record

A shared platform is easier to govern when its decision record is explicit. The following fields illustrate a useful internal model; they are not a proposed common Australian and New Zealand statutory form.

The record should explain the decision rather than merely collect fields. A complete timestamp set is not enough if nobody knows what each timestamp means. A status called “approved” is not enough if the approving user lacked the relevant delegated authority. A report reference is not enough if it cannot be connected to the exact version of the narrative and transaction population that was sent.

Preserve the trigger when work moves between teams

The fictional group operates a shared investigation centre. An Australian case can be reassigned between shifts, and a New Zealand case can be escalated to a regional specialist. Those transfers should change the operational owner without silently resetting the legally relevant chronology.

The requirements should distinguish transaction time, alert creation, first review, the point at which a suspicion is formed, internal approval, submission and response. These moments can be different. The interface should not imply that a filing clock begins only when a manager opens the task unless that reflects the applicable legal trigger. A retrospective edit to a key time should require a reason and an audit trail rather than simply improving the service-level dashboard.

Local compliance should define the applicable timing rules, including the treatment of different report categories and calendar conventions. The technology team should implement those definitions without inventing one regional countdown. The test suite should cover weekends, daylight-saving changes, reassignment, late-arriving information and an interruption to the submission service. These are proposed resilience tests; their expected legal outcomes must come from the relevant local interpretation.

AUSTRAC's suspicious matter reporting guidance is the starting point for the Australian reporting decision and timing requirements. It should not be replaced by an internal service target or a New Zealand rule copied into an Australian configuration. Primary source: AUSTRAC's suspicious matter report guidance.

Reconcile reports beyond the submit button

In a fictional test, the platform prepares 200 local reports. It receives positive responses for 198, while two requests lose their responses during a connection failure. The correct operational conclusion is not that all 200 failed, nor that all 200 succeeded. The two uncertain outcomes need controlled reconciliation with the actual receiving service.

The application should retain its internal report identity, the local entity, report type, version, submission attempt and any external reference. A retry should follow the receiving service's documented procedure. Generating a fresh submission indiscriminately may create a duplicate; assuming that an unanswered request succeeded may leave an obligation unfulfilled. The bank needs a supported way to distinguish those states.

The same principle applies to amended information. A corrected narrative should be connected to the earlier report and the reason for amendment. Operations should not delete the original payload to make the current record look tidy. The bank must be able to explain what it knew when it first reported and what changed later, while following the actual local process for corrections or additional information.

A report-reconciliation queue should be separate from the investigation queue, even when they share the same screen. An investigation can be complete while a technical acknowledgement remains unresolved. A report can be accepted while customer-risk review or account action remains open. The dashboard should let managers see both kinds of unfinished work rather than allowing one green status to conceal the other.

Define failure behaviour before the cutover

A shared regional service can fail in a way that affects only one country's controls. An Australian report adapter may reject a field that the New Zealand adapter accepts. A New Zealand reporting credential may expire while internal investigations continue normally. An entity-classification service may be unavailable even though the payment engine is healthy.

The release plan should define the response to each failure in terms of the affected obligation and business activity. It should identify the incident owner, available evidence, authorised contingency and escalation path. A broad instruction to “continue manually” is incomplete unless the manual team has access, authority, capacity and a way to reconcile the resulting records with the platform after recovery.

Contingencies should also preserve confidentiality. An outage does not justify sending unrestricted case files to a general collaboration channel or allowing an unapproved external service to process them. The proposed emergency process should specify what information can be shared, with whom, through which approved channel and how access is removed afterwards.

Rollback requires similar care. Restoring the previous software version does not reverse a customer decision, withdraw a report or erase an investigation. The rollback plan should distinguish technical state from business events that already occurred. Where the old software cannot represent a newly created record, the team needs a controlled compatibility or reconciliation procedure rather than assuming the database can simply be rewound.

Build a release evidence pack that another team can challenge

For this fictional implementation, the release owner assembles a compact evidence pack. It contains the approved country profiles, the mapping between legal obligations and configuration, the changed customer classes, representative decision records, reporting-interface test results, unresolved defects and the relevant operational sign-offs. The pack should make the scope of the claim visible: what was tested, under which configuration and with which limitations.

A useful sample traces one Australian and one New Zealand case from source facts through decision, submission and acknowledgement. It also includes a non-reportable case with a reasoned outcome, because an effective system should support justified decisions not to report as well as justified reports. A third sample should exercise a failure path and demonstrate that the resulting open work is visible to the correct owner.

Independent reviewers should challenge the relationships between records. Does the reported transaction population match the case? Did the local authorised person make the decision? Can the bank show the policy version used at that time? Did a customer-data update accidentally alter historical evidence? Does the reporting dashboard reconcile to the receiving service rather than merely to the internal outbound queue?

The acceptance decision should not be reduced to a count of passing technical tests. A small unresolved defect may be material if it affects the ability to meet a legal obligation or preserve confidential information. A large number of cosmetic defects may have a different risk profile. The decision-maker needs the nature of the risk, the affected population, the available mitigation and the accountable owner, not just a numerical severity score.

Keep the platform honest after implementation

Once the release is live, the same country profiles should support change management. A new guidance document may require a legal interpretation before a configuration change; a changed reporting interface may require technical regression without altering the underlying suspicion threshold. The bank should record which kind of change it is making and who is authorised to approve it.

Operational measures should connect customer experience with control effectiveness. Examples include unresolved applicability cases, ageing reporting acknowledgements, repeated information requests caused by internal data loss, decisions requiring retrospective correction and access exceptions awaiting closure. These measures reveal whether the shared platform is reducing duplication responsibly or merely shifting unresolved work between teams.

The central design lesson is that reuse should occur at the level of capabilities, not by pretending that two legal systems are the same. A common evidence store, workflow engine and interface framework can be valuable. Their success depends on preserving the local decision, its authority, its timing and its proof.

Advanced practice: architecture, data and testing across two regimes

A regional platform becomes safe when it can reuse technology without erasing jurisdiction. The design question is therefore where to draw the boundary between shared capability and local rule.

Use a country-rules layer

A bank does not need two customer masters, two screening engines or two case platforms simply because Australia and New Zealand have different laws. It does need an effective-dated rules layer that identifies jurisdiction, legal entity, regulated service, trigger, required data, deadline, report destination, transition condition and source reference. Historical cases must retain the rule version that was active when the event or decision occurred.

Shared services can then remain genuinely shared. CDD can use common identity and beneficial-ownership objects. Payment enrichment can preserve party roles and end-to-end references. Screening and monitoring can use common event models. Case management can use a common chronology and evidence model. Reporting can use shared validation and gateway services. The local rule determines what is mandatory and which authority receives the outcome.

Keep customer identity and payment identity distinct

The account holder is not necessarily every party in a payment. A corporate customer can send a payment containing an ultimate debtor, beneficiary, intermediary institutions and remittance references to other parties. Screening only the account holder misses transaction risk; treating every beneficiary as a customer creates false relationships. The regional data model should preserve party role, source system, original value and transformed value where a payment is mapped between formats.

That model supports Australia's transfer and travel-rule controls and New Zealand's wire-transfer, prescribed-reporting and suspicious-activity analysis without pretending the legal requirements are identical.

Build cases around legal decisions

An alert is a signal, not a legal conclusion. A case is an investigation container. Suspicion is a reasoned local decision. A regulatory report is an external filing. A sanctions disposition is a separate legal decision. Customer restriction or exit is a relationship decision. The platform should let these outcomes coexist without collapsing them into one generic status.

Access should reflect sensitivity. Investigators may need broad transaction context, while only authorised users should approve or edit externally reported suspicion narratives. Restricted report text should not be copied into general CRM notes. View, edit, approval and submission actions should be auditable.

Test the jurisdiction boundary, not only the happy path

A useful test pack should prove that Australian rules do not leak into New Zealand and vice versa. Test an Australian domestic payment with no suspicion; a New Zealand qualifying international transfer; an Australian terrorism-financing suspicion; a New Zealand suspicion below prescribed-transaction thresholds; a cross-border AU-to-NZ transfer; a true and false sanctions match; an external-report rejection; an outage close to a deadline; and events immediately before and after a rule's effective date.

Negative testing is essential. A New Zealand report should not be created because an Australian rule matched similar data. A false sanctions hit should clear without automatically increasing AML risk. Missing jurisdiction context should route to a controlled exception instead of silently applying a regional default.

Reconciliation proves coverage

Financial-crime controls need reconciliation between source populations and processed populations. The bank should be able to demonstrate that all in-scope payments reached screening, all eligible events reached monitoring, and all externally required reports generated by rules were either submitted or have a controlled exception. For regulatory reporting, a strong three-way reconciliation links source events, internally generated reports and authority acknowledgements.

Management information should then be diagnostic: overdue reports, rejected submissions, customer-review backlog, monitoring coverage, unresolved sanctions holds, data-quality defects, open reform actions and repeat QA failures. Volume alone does not prove effectiveness.

The architectural test of maturity is simple: the bank should be able to change an Australian rule without breaking New Zealand processing, change a New Zealand rule without redeploying unrelated Australian logic, and still give a regional investigator enough connected evidence to understand a cross-border case.

Practice close: requirements, acceptance criteria and assurance

For example, when an authorised Australian decision-maker records that the local suspicion threshold is met, the case service should preserve the suspicion-formation timestamp, linked parties and transactions, approval history and applicable AUSTRAC report version, then route the report to an Australian regulatory-reporting queue with the correct deadline logic. The equivalent New Zealand requirement should identify the New Zealand reporting entity, local suspicion event, Police FIU/GoAML destination and New Zealand clock. The workflow capability may be shared; the legal rule cannot be generic.

A production-ready country-rules service should prove that every rule is linked to jurisdiction and legal entity, carries effective dates and source references, retains historical versions, constrains allowed report outcomes, uses the correct business-day calendar, records authorised overrides and routes unresolved jurisdiction context to a controlled exception rather than a default country.

CDD testing should include individuals, layered corporate ownership, higher-risk relationships, ownership changes and event-driven review. For Australia, include an eligible transitional customer and prove that the procedural basis is stored without erasing history when the customer later moves to the current CDD state. For New Zealand, test the current identity-verification journey, failed verification, approved exceptions and retention, and prove that the 1 July 2026 supervisor change does not redirect FIU reporting away from Police GoAML.

Payment testing should include domestic and cross-border transfers, intermediary institutions, missing party data, returns and a transfer touching both group entities. For Australia, verify the institution's transfer role and applicable travel-rule handling. For New Zealand, test a transaction that meets prescribed international-transfer conditions and one below the threshold. Separately test suspicious activity below any prescribed threshold to prove that suspicious reporting remains independent.

Sanctions tests should include a false match, a true listed-person match, an ownership/control question and an activity restriction that is not a simple list hit. The result must be recorded separately from AML suspicion and use the correct local legal source.

Before production sign-off, the control owner should be able to prove that in-scope source events reached screening and monitoring; external reports can be reconciled to source events and authority acknowledgements; rule versions are recoverable; suspicion formation is distinguishable from alert creation and report submission; Australian AUSTRAC interaction is distinguishable from New Zealand DIA supervision and Police FIU reporting; sanctions decisions use the correct jurisdictional framework; and outages or report rejections have tested runbooks.

Masterclass: a trans-Tasman payments investigation

This fictional case follows realistic banking mechanics and shows why shared intelligence and local legal decisions must coexist.

Harbour Equipment Group is a New Zealand-owned industrial wholesaler. Its parent banks in Auckland and its Australian subsidiary banks with the same group in Sydney. They share directors and a treasury function. The Australian company normally pays domestic suppliers; the New Zealand parent receives trading revenue and pays established overseas manufacturers.

Over six weeks the Australian subsidiary begins receiving more intercompany funding from New Zealand and sending most of it within 24 hours to two new overseas suppliers. The payments are not individually exceptional by value, but behavioural monitoring detects the new corridor, new counterparties and rapid onward movement. At the same time, the New Zealand parent receives repeated credits from an unrelated local property-maintenance company and transfers part of the value to Australia. New Zealand monitoring creates a separate alert.

A regional entity service links the two customers through verified ownership and shared directors. The Australian and New Zealand cases remain owned by their respective legal entities, but investigators can use lawfully shareable information to understand the combined flow.

The Australian investigator requests invoices and commercial explanation. The invoices describe electronic components in broad terms and direct payment to accounts outside the suppliers' registered countries. That is not proof of laundering, but it requires corroboration. The New Zealand customer explains that the unrelated credits are repayments of a private loan made by one of its directors. That introduces a new question: why is the company's operating account receiving funds connected to a director's personal financing arrangement?

The bank tests the explanations against customer purpose, source-of-funds evidence, ownership, counterparties and transaction history. It does not treat novelty as guilt. The strength of the investigation comes from whether the combined evidence coherently explains the activity.

The Australian authorised decision-maker eventually concludes that the Australian suspicion threshold is met. The case records the suspicion-formation time, linked transactions, parties, reasoning and approval, and the Australian entity submits the appropriate SMR to AUSTRAC within the applicable filing period. The New Zealand team makes its own decision under New Zealand law rather than copying the Australian conclusion. It independently concludes that reasonable grounds for suspicion exist and submits the appropriate report to the Police FIU through GoAML within the applicable New Zealand timeframe.

The two reports are related, but one is not a substitute for the other. Equally, if only one legal entity had reached its local threshold, symmetry would not be a valid reason for the other to file.

Before another Australian payment is released, sanctions screening identifies a potential match on a supplier director. The sanctions team resolves identity and then determines which sanctions regimes legally apply, whether ownership or control affects the supplier, and what operational disposition is required. That analysis remains separate from the AML suspicion. A false sanctions match would not erase the AML concerns; a true sanctions match would not automatically satisfy suspicious-reporting obligations.

Months later, internal audit should be able to reconstruct the customer profiles that existed at the time, the ownership link, payment records, monitoring triggers, rule versions, evidence requests, investigator chronology, Australian SMR decision, New Zealand GoAML decision, sanctions analysis and any remediation to customer risk or control design. If the bank can produce only the final external reports, too much of the control evidence has disappeared.

The case demonstrates the central operating principle: share evidence to improve understanding, but preserve country-specific reasoning for legal outcomes.

References and further reading

Australia: AML/CTF regulation and financial intelligence

• AUSTRAC, About AUSTRAC — confirms AUSTRAC's dual role as Australia's AML/CTF regulator and financial intelligence unit: https://www.austrac.gov.au/about-us/what-we-do/about-austrac
• AUSTRAC, Changes to AML/CTF obligations: What you need to do, published 1 July 2026 — current reform implementation for existing reporting entities: https://www.austrac.gov.au/news-and-media/article/changes-amlctf-obligations-what-you-need-do
• AUSTRAC, New reporting regime now in force, published 1 July 2026 — newly regulated sectors and updated reporting arrangements: https://www.austrac.gov.au/news-and-media/article/new-reporting-regime-now-force
• AUSTRAC, What to expect from the changes to the AML/CTF Rules, published 26 March 2026 — travel rule, initial CDD transition and other transitional arrangements: https://www.austrac.gov.au/news-and-media/article/what-expect-changes-amlctf-rules
• AUSTRAC, AML/CTF transitional rules 2026 — official transition guidance and effective-date considerations: https://www.austrac.gov.au/about-us/legislation/updates-legislation/amlctf-transitional-rules-2026
• AUSTRAC, Suspicious matter reports, last updated 9 September 2026 — current SMR decision and filing-time guidance: https://www.austrac.gov.au/industry-and-business/obligations-and-guidance/your-amlctf-program/reporting-us/suspicious-matter-reports
• AUSTRAC, Step 5: Conduct an independent evaluation — current expectations for independent evaluation of AML/CTF programs: https://www.austrac.gov.au/industry-and-business/obligations-and-guidance/your-amlctf-program/develop-your-amlctf-programs/step-5-conduct-independent-evaluation
• AUSTRAC, Our regulatory expectations — 2026–27 supervisory expectations: https://www.austrac.gov.au/about-us/policies-and-governance/our-policies/our-regulatory-expectations-and-priorities/our-regulatory-expectations
• FATF, Australia Follow-Up Report 2024 — international technical-compliance context: https://www.fatf-gafi.org/en/publications/Mutualevaluations/Australia-fur-2024.html

New Zealand: supervision and financial intelligence

• New Zealand Ministry of Justice, Legislative changes — Anti-Money Laundering and Countering Financing of Terrorism (Supervisor, Levy, and Other Matters) Amendment Act 2026 and 1 July 2026 changes: https://www.justice.govt.nz/justice-sector-policy/key-initiatives/aml-cft/legislate-changes/
• New Zealand Ministry of Justice, Information for businesses — transition from three AML/CFT supervisors to DIA as sole supervisor: https://www.justice.govt.nz/justice-sector-policy/key-initiatives/aml-cft/info-for-businesses/
• Department of Internal Affairs, AML/CFT Homepage — current sole-supervisor entry point and guidance: https://www.dia.govt.nz/AML-CFT-Homepage
• Department of Internal Affairs, New Era for AML/CFT regulation as DIA Launches Comprehensive Guidance Suite, 1 July 2026: https://www.dia.govt.nz/New-Era-for-AML-CFT-regulation-as-DIA-Launches-Comprehensive-Guidance-Suite
• Department of Internal Affairs, New Identity Verification Code of Practice, 4 June 2026 — code commencing 1 July 2026: https://www.dia.govt.nz/AML-CFT-New-Identity-Verification-Code-of-Practice
• Department of Internal Affairs, Annual AML/CFT Report — current supervisory reporting information: https://www.dia.govt.nz/AML-CFT-Annual-Report
• New Zealand Police, NZ Financial Intelligence Unit — FIU role, report types and GoAML reporting: https://www.police.govt.nz/advice/businesses-and-organisations/fiu
• New Zealand Police, Suspicious Activity and Transaction Reports — current three-working-day SAR filing guidance: https://www.police.govt.nz/advice/financial-intelligence-unit-fiu/suspicious-activities-and-transactions-reports
• New Zealand Police, Prescribed Transactions Reporting — international funds transfer and large-cash reporting definitions: https://www.police.govt.nz/advice-services/businesses-and-organisations/nz-financial-intelligence-unit-fiu/prescribed
• New Zealand Police, GoAML – Financial Intelligence Unit Reporting Tool — prescribed FIU reporting channel: https://www.police.govt.nz/advice/businesses-and-organisations/fiu/goaml
• DIA AML Online, Suspicious activity reports — no monetary threshold and confidentiality context: https://aml.dia.govt.nz/knowledge-article/KA-01033
• New Zealand Ministry of Justice, AML/CFT National Strategy 2026–2030 announcement and work programme context: https://www.justice.govt.nz/about/news-and-media/news/government-releases-new-strategy-to-protect-new-zealanders-from-money-laundering/

Sanctions: keep the legal lane separate from AML/CFT

• Australian Department of Foreign Affairs and Trade, Consolidated List — Australian Sanctions Office source for persons, entities and vessels subject to Australian sanctions: https://www.dfat.gov.au/international-relations/security/sanctions/consolidated-list
• Australian Department of Foreign Affairs and Trade, About sanctions — scope and operation of Australian sanctions laws: https://www.dfat.gov.au/international-relations/security/sanctions/about-sanctions
• New Zealand Ministry of Foreign Affairs and Trade, Overview of sanctions against Russia — New Zealand's autonomous Russia sanctions and relationship to UN sanctions: https://www.mfat.govt.nz/en/countries-and-regions/europe/ukraine/russian-invasion-of-ukraine/sanctions/overview-of-sanctions-against-russia
• New Zealand Ministry of Foreign Affairs and Trade, Who to contact — current sanctions contact and reporting routes: https://www.mfat.govt.nz/en/countries-and-regions/europe/ukraine/russian-invasion-of-ukraine/sanctions/who-to-contact