Three CRM AML Compliance Architectures Are Emerging Ahead of Tranche 2. Here’s How to Tell CRM-Embedded, Portal-First and Compliance-First Designs Apart.

Part 1 asked what to look for when a CRM claims to have compliance built in. This piece steps back from the vendors and looks at the architectures underneath them. The choice between those architectures is more consequential, and more durable, than the choice between specific products.

As Australian real estate businesses prepare for Tranche 2, identity-verification products are moving quickly into the CRMs agencies already use. That’s a good thing, and it reflects real work by capable vendors. But not every integration is doing the same thing. Underneath similar-sounding marketing, three distinct architectural approaches have emerged, and each solves a different part of the AML/CTF obligation.

Knowing which architecture you’re looking at matters more than knowing which vendor is behind it. The architecture determines who does compliance work, where the evidence lives, how the compliance officer maintains independence, and how exposed the agency is to tipping-off risk. Those questions outlast any particular product choice.

In practice, the architecture you choose will shape who asks the customer for information, who can see the result, where the evidence sits, and whether your compliance officer is working in a genuinely independent workflow or inside the sales system.

The Three Patterns at a Glance

CRM-embedded identity verification. The compliance trigger, status, and report live inside the sales CRM. The customer journey starts from a contact or listing record, and the result flows back to the same record. Examples in the Australian market include Rex’s native First AML integration and APLYiD’s announced Rex integration and partnership. Similar patterns are appearing across other CRM vendors as they partner with identity-verification specialists.

Portal-first with CRM status pushback. A dedicated AML platform with its own officer workspace, plus a webhook or API that reflects case status back into the CRM. Many incumbent AML providers sit here, along with many platforms that grew up serving law firms and accountants before Tranche 2 reached real estate.

Compliance-first with CRM integration. The AML platform holds the full compliance workflow, the compliance officer’s permissions, and the evidence. It integrates with the CRM through neutral-vocabulary status pushback and sealed evidence references, not by exposing the compliance workspace inside the sales system. This is the architecture AML Guard is built around, and we’ll disclose that openly when we get to it.

All three are legitimate design choices. They’re optimising for different things and they fit different types of firm.

Architecture 1: CRM-Embedded Identity Verification

What this pattern does well

Identity verification is the most frequent, most time-sensitive, and most customer-facing step in customer due diligence. Putting it inside the CRM where the listing is created, the contact is loaded, and the property record lives removes friction that would otherwise cost admin staff real hours per day. APLYiD’s biometric flow — SMS link, two-minute selfie and document capture, verification returned before the agent has hung up the phone — is genuinely strong UX. First AML’s ISO-accredited case management, global jurisdictional coverage, and REIA endorsement give it depth that goes beyond identity alone. Both vendors have built capable products, and for agencies whose volume is predominantly individual residential vendor and purchaser checks, this pattern works.

What the pattern is scoped to cover

Individual identity verification — biometric or document-based — plus PEP and sanctions screening, adverse media, optional ongoing monitoring, and status pushback to the CRM. That’s a complete product in its own right, and it handles a substantial share of a small agency’s day-to-day AML workload.

Where the scope boundary sits

Agencies should be aware of what the CRM-embedded layer does not cover by design. This is not a criticism — it’s a boundary that matters because “CRM-integrated AML” and “CRM-complete AML program” are not the same thing.

• Company and trust verification beyond listing individual beneficial owners. The ownership discovery step, entity structure mapping, and verification of the entity itself typically happen in the vendor’s own portal, not in the CRM.
• Source of funds and source of wealth assessments. These generally sit outside the CRM-embedded flow.
• Risk assessment, customer acceptance decisions, and enhanced due diligence trigger management.
• Case management, escalation paths, and compliance officer sign-off queues.
• Policy documentation, staff training records, and the audit artefacts needed for the required independent evaluation of the AML/CTF program.

Some of these sit in the vendor’s portal alongside the CRM integration; some are in adjacent products; some require separate workflow entirely. The point is that the vendors haven’t left gaps — they’ve drawn a product scope. Agencies need to understand where that scope ends.

Pressure points the pattern creates

These apply to any vendor taking the CRM-embedded approach, not to First AML or APLYiD specifically. They’re properties of the architecture.

Segregation of duties

A CRM is a sales system. Its users are listing agents, buyer’s agents, property managers, and administrators — people whose commercial incentive is to close the transaction. AUSTRAC’s program guidance expects the AML/CTF Compliance Officer to have sufficient authority and independence to oversee compliance, with governance separated from revenue-generating functions. When compliance triggers, status, and evidence sit inside the sales CRM, that functional separation has to be rebuilt through permission configuration. The architecture doesn’t enforce it; the agency has to. This matters even in smaller agencies where one person may perform multiple governance roles, because the system still needs to preserve clean authority, visibility, and decision controls over who can see, escalate, and clear compliance issues.

Tipping-off exposure

Section 123 of the AML/CTF Act makes tipping off a criminal offence where a disclosure would, or could reasonably be expected to, prejudice an investigation. For agencies, the practical point is that status language, evidence visibility, and follow-up workflows need to be designed so staff do not inadvertently disclose that a matter is under suspicion or has been escalated.

Status labels like “failed” or “under review” visible to a sales agent on a contact record, downloadable screening reports attached to a listing, and notes left on review-stage adjudications all create pathways by which a sales agent could inadvertently signal a compliance problem to the customer. A well-meaning follow-up call — “there’s a hold-up on the ID check, can you resubmit?” — is exactly the kind of disclosure s123 is written to prevent. The architectural mitigation is a pre-approved neutral status vocabulary, restricted visibility of screening evidence, and permission gating on the report. All of that is configurable. None of it is the out-of-the-box posture.

Adjudication authority

CRM-embedded workflows typically let any authorised user move a case from “review” to “verified” with a note. The audit trail records who did it. It doesn’t establish whether they had the authority to. Whether that matters depends on how your agency wants to separate deal-closing from compliance-clearing, and how robust your policy is about who can actually make that call.

Ask: Is the CRM-embedded integration you’re evaluating handling identity verification and screening, or does it claim to handle the full CDD lifecycle? What specifically stays in the vendor’s portal, and where does your compliance officer do their work?

Architecture 2: Portal-First with CRM Status Pushback

What this pattern does well

Keeps compliance workflows, permissions, and evidence in a purpose-built environment. The compliance officer has their own workspace. Cases carry entity structures, ownership trees, source-of-funds documentation, risk assessments, and screening history natively. The CRM receives a neutral status update through a webhook or API call. Functional separation is clean by default: sales is sales, compliance is compliance, and the integration is a thin status bridge between them.

What it trades off

Friction at the top of the workflow. In the purest version of this pattern, admin or compliance staff need to re-key customer details from the CRM into the AML portal to start a case. That double-keying is exactly the efficiency gap CRM-embedded architectures are designed to close. For an agency doing ten vendor verifications a week, it’s a meaningful productivity hit that lands squarely on admin staff.

Who it fits

Agencies with an established compliance function, law firms and accounting firms where the AML platform serves multiple regulated activities, and any firm where the compliance officer sits organisationally separate from the sales function. It’s also often the right pattern for franchise networks where head office owns compliance and individual offices own sales.

Ask: If you’re evaluating a portal-first platform, how much of the customer record transfer is actually automated? Is there a way to trigger a case from the CRM side, or does every case start with manual re-keying?

Architecture 3: Compliance-First with CRM Integration

What this pattern does

The AML platform holds the full compliance workflow — identity verification, screening, entity and beneficial owner verification, risk assessment, customer acceptance policy, source of funds, enhanced due diligence triggers, ongoing monitoring, case management, suspicious matter report preparation, and audit artefacts. The compliance officer’s permissions, queues, and adjudication authority are native to the AML platform, not inherited from the CRM.

Integration with the CRM is bidirectional where the CRM’s API allows it, but deliberately scoped. What flows into the CRM is a neutral-vocabulary status label and a sealed evidence reference — not the underlying screening result, not the risk rating, not the reason for a held status. What flows from the CRM into the AML platform is customer identity, listing context, and, where the CRM supports it, trust account data for compliance investigations.

What it requires of the agency

A willingness to treat compliance as a workflow rather than a widget. Two systems — the CRM as system-of-record for sales, the AML platform as system-of-record for compliance — means some users need access to both. For the very smallest agencies, where the principal wears every hat, this can feel like more machinery than the task requires. For any agency past that size, the separation tends to pay for itself the first time a compliance decision has to stand up to scrutiny.

Who it fits

Agencies with distinct compliance and sales functions, multi-office operations, firms handling a meaningful volume of entity transactions (companies, trusts, SMSFs), and any agency that expects to face AUSTRAC scrutiny and wants a clean architectural answer to the question “who saw what, when, and who was authorised to clear it.” Law firms adding real estate conveyancing tend to arrive here by default because their compliance function already exists.

Disclosure

This is the architecture AML Guard is built around. We’ve written about it in this series because we believe Tranche 2 will push more agencies toward needing it — not because we think the other patterns are wrong. Smaller agencies doing predominantly individual residential checks will reasonably conclude that CRM-embedded identity verification handles enough of their obligation. Larger agencies, entity-heavy firms, and firms bundling real estate with other regulated services may reasonably conclude otherwise. Both conclusions are defensible. What matters is that the conclusion is made with clear eyes about what each architecture is and isn’t doing.

Ask: Where does the compliance officer do their work? If the answer is “inside the sales CRM,” the architecture is doing something different from one where the compliance officer has an independent workspace with independent permissions.

Six Questions That Reveal the Architecture

Marketing language is converging — every vendor now says “integrated,” “end-to-end,” “complete compliance.” The architecture is what the product actually does, regardless of what it calls itself. Six questions will usually tell you which pattern you’re looking at.

1. Where does the compliance officer do their work? In the sales CRM, or in a dedicated workspace?
2. Where do company, trust, and partnership CDD cases live? In the CRM, or in the vendor’s portal?
3. What vocabulary flows into the CRM as status? “Verified / failed / under review,” or a neutral pre-approved vocabulary designed around tipping-off obligations?
4. Can compliance visibility be configured independently of CRM permissions? Or does the same principal or office administrator who controls sales access also control compliance access?
5. Who can move a case from “under review” to “verified”? Any authorised CRM user with a note, or a designated AMLCO or delegate with a separate authorisation trail?
6. What’s the data portability story if you change CRM, change AML vendor, or face an AUSTRAC audit — which system holds the authoritative copy of the evidence, and can you extract it cleanly?

The answers will tell you which architecture you’re actually buying, regardless of what the vendor’s marketing calls it.

The Question Isn’t Which Vendor

Tranche 2 doesn’t prescribe an architecture. It prescribes outcomes: an AML/CTF program that is in place and followed, customers identified and verified appropriately, a documented risk assessment, governance roles that are actually empowered, staff training and oversight that work in practice, records that demonstrate compliance, and an independent evaluation cycle that stands up when tested. Any of the three architectures above can deliver those outcomes for the right type of firm.

The real question is which architecture matches how your agency actually makes compliance decisions, where you want your compliance officer to sit in the organisation, and how much governance separation you need between the people closing deals and the people clearing them. A single-office boutique with one principal and three agents has a different answer to that question than a twelve-office franchise group with a dedicated compliance officer and fifty agents. Both answers can be right.

1 July is a date. Architecture is a choice you’ll live with for far longer.

Sources

• AUSTRAC — AML/CTF program overview
• AUSTRAC — AML/CTF compliance officer guidance
• AUSTRAC — Tipping off guidance
• AML/CTF Act 2006 — section 123 (legislation.gov.au)

Last reviewed: April 2026.

Ready to see AML Guard in action?

AML Guard covers the full AML/CTF program lifecycle — from CDD case management and identity verification to beneficial ownership tracing, risk scoring, program governance, AUSTRAC reporting, and CRM integration. Book a 20-minute demo.

Book a Demo

Related Reading

• Part 1: Built-In CRM Compliance Sounds Convenient. Five Questions to Ask Before You Rely on It.
• When Does AML Compliance Actually Start in a Property Transaction?
• What AML/CTF Program Documents Do You Need Before 1 July 2026?
• Beneficial Ownership: How to Trace UBOs Under Tranche 2

This article is for general information purposes only and does not constitute legal or compliance advice. The information reflects current AUSTRAC reform guidance as at the date of publication. Firms should obtain independent professional advice on their specific AML/CTF obligations. Capabilities, integrations, and pricing for any vendor referenced should be confirmed directly with the vendor before purchase decisions are made.