Darren Hosiosky
Somewhere in your firm there's a client list with a few hundred names on it, and someone has been asked to work out which ones need an ID check.
That's the actual job. Not the checks themselves, which are quick once you've started. The hard part is the decision that comes first, and it's where most firms are still guessing.
What the code actually says
There are two triggers:
Before you commence a designated service
When a client's risk profile changes
That's the whole test.
It reads cleanly until you try to apply it to a real list. Is preparing this year's return for a client you've had since 2003 the commencement of a designated service? Does appointing a new trustee change a risk profile? Two careful readers land in different places.
The interpretation sits with your firm, and nobody can hand you the list. What follows is the three cases where firms get stuck most often, and what a defensible answer looks like in each.
Do you need to verify a client you've had for 30 years?
This is the one partners ask when they're staring at a list of people they've known for decades.
You're not verifying because you think the client is a risk. You're verifying because the code requires a documented check at certain points, and "I've known Bob since 2003" isn't a record. If you're preparing a return, you're providing a designated service. Whether that counts as commencing one for an existing client is where the judgement sits.
What matters in practice is that your reasoning is written down. A firm that verified 200 clients and documented why it skipped 300 is in a strong position. A firm that verified all 500 but can't explain the logic is in a weaker one than it thinks. A firm that did nothing has no position at all.
So the useful question isn't "do I have to?" It's "can I show how I decided?"
What about a discretionary trust with unnamed beneficiaries?
Discretionary trusts are the hard part, and it's worth being specific about why.
There's no public record of the beneficiaries, the trustees or the settlor. ASIC won't help. The information exists in the deed and nowhere else, which is why so much of this work still involves someone reading a document by hand and taking notes.
Deeds also don't name people neatly. A beneficiary might be described as the offspring of a named individual. If that person has no children yet, there's nobody to verify. But you can't leave a blank in the file and hope the question never comes.
The way through is to treat "not required" as a finding rather than an absence. Read the deed, identify every party, and record the ones who don't need verifying alongside the reason. When you're asked to show your working, the answer is a document rather than a recollection.
Does a client with ten entities get verified ten times?
This is one of the most common questions we get, and the answer should be no.
An individual is an individual. Once you've verified someone's identity, that verification ought to carry across every entity they're connected to. They submit documents once, you pay for one check, and the link between the person and their entities is what gets recorded.
If your process runs a fresh check per entity, you're paying ten times for the same information and asking your client for their driver's licence ten times. Clients notice, and the pushback lands on your admin team rather than on your software vendor.
Why this stalls even when firms know what to do
Three things, and none of them are about the checks.
Verification lives somewhere else. You're preparing a return in one system and running an ID check in another. So it becomes a separate task, and separate tasks get scheduled for later. Later tends to mean October.
Clients think it's a scam. An unexpected email asking for a driver's licence looks exactly like phishing, because that's what phishing looks like. So the client rings the office, and your team spends the morning reassuring people instead of working. Telling clients what's coming first, on your letterhead, in your firm's name, prevents most of those calls.
Failed checks come back without a reason. "Verification failed" tells you nothing. Usually it's an expired licence or passport. If you can see that, you can tell the client exactly what to fix. If you can't, you send them round the loop blind and lose another week.
What it looks like when it's built in
Here's how Admiin handles the same three cases.
Verification runs inside the lodgement workflow, at the point you're already looking at the client, rather than as a job for later.
A warm-up email goes out first, from your firm, explaining the new requirements and what's about to arrive. This is the part that cuts down the "is this real?" phone calls.
Trust deeds get read for you. Upload the deed and you get the trustee, the appointor, the settlor and the beneficiaries back in about two minutes, with any party that doesn't need verifying recorded as not required.
An individual verifies once. They're linked to their connected entities, so ten entities don't mean ten checks or ten requests for a driver's licence.
Failed checks tell you why they failed, so you can tell the client exactly what to fix.
You get a CDD report with your firm's logo on it, which is what you hand over if you're ever asked to show how you decided.
Pricing is pay as you go and itemised line by line. An individual is capped at $5.15, and you can see which check cost what.
Still working out who needs verifying?
We built a free tool for exactly that question. No account, no signup. Ask it about a client type, and it'll walk you through what the code says.
And if you'd rather see verification running inside a lodgement than beside it, the rest of Admiin is free to use. The e-signing, the cover letters, the follow-ups. You pay when you verify.
