Setting up new users in NAB Connect, properly and safely

Administration is a security job wearing an HR costume

Most business banking losses do not begin with a hacker in a hoodie. They begin with access that was too broad, granted in a hurry, and never reviewed: the casual staffer who could authorise payments "just for that one busy week" three years ago; the bookkeeper who left in March and whose login still worked in October; the shared office password known by everyone who has ever temped at the front desk. As the administrator, you are the person standing between your organisation and that entire category of loss. The technical steps of creating a user take five minutes. The thinking around them — who should be able to do what, and why — is the real work, and it is what this guide concentrates on.

Three principles run through everything below. Least privilege: every user gets the minimum access their actual job requires, and nothing "just in case". Separation of duties: the person who creates a payment should not be the only person who can release it, wherever the size of your team allows that split. Named accountability: every credential belongs to one identifiable human. The moment a login is shared, your audit trail — the record the bank, your insurer and possibly a court will rely on — becomes worthless. Hold those three lines and most of the detailed rules in this guide are just their working-out in practice.

Roles and permissions: decide the shape before you create anyone

Resist the urge to open the admin screen and improvise. Roles built on the spot tend to mirror whoever asked loudest, and they fossilise. Instead, map your organisation's money jobs first. In a typical small or mid-sized business the work sorts itself into four broad roles, and NAB Connect access should be built to match them.

Viewers can see balances, transactions and statements but cannot move money: think external accountants, auditors during an engagement, or owners who want oversight without operational access. Creators prepare payments — entering supplier payments, building payroll batches, setting up BPAY bills — but cannot release them. This is the natural role for bookkeepers and accounts-payable staff. Authorisers review and release what creators prepare, usually within a personal dollar limit. Owners, finance managers and senior staff sit here. Administrators manage the users themselves: creating logins, assigning roles, resetting credentials. In a small business the owner is often both the sole administrator and an authoriser — workable, but recognise the concentration of power and compensate with extra care, because there is no second pair of eyes on you.

Two design decisions deserve explicit thought. First, account-level access: not every user needs to see every account. Payroll accounts, tax accounts and holding accounts can be restricted to the people whose jobs touch them, which limits both error and temptation. Second, who can create beneficiaries and templates. Payment fraud in Australian businesses very often works by quietly altering where money goes — a changed supplier account number — rather than by creating obviously bogus payments. Treat beneficiary maintenance as a sensitive permission in its own right, and consider reserving it to senior roles or requiring an authoriser's involvement.

Creating a user: the working sequence

Exact menu labels vary as the platform evolves, so treat this as the working sequence rather than a keystroke map, and confirm labels against the current interface and the bank's own administrator documentation as you go.

1. Verify the request off-platform first

   Before creating anyone, confirm the request through a channel you trust — a conversation with the manager, the signed internal form, the HR advice. A user-creation request that arrives by email alone, especially one urging speed, deserves a phone call. Administrator accounts are the keys to the kingdom, and social engineers know it.

2. Create the user with their real, full identity

   Use the person's actual name and their own work contact details. Never create users named "Accounts", "Reception" or "Temp". A login that cannot be tied to a human is a future investigation's dead end.

3. Assign the role you designed — not the maximum available

   Attach the role from your plan (viewer, creator, authoriser), the specific accounts the job touches, and any function restrictions. If the platform offers a template role, review every permission inside it before using it; templates are starting points, not decisions.

4. Set the authorisation limit, if the role can authorise

   Set it to the value of payments this person genuinely releases in a normal week, with sensible headroom — not to the largest payment the business ever makes. Section 3 below covers limit-setting in detail.

5. Issue credentials and a token through separate channels

   The starting password or activation details and the token (physical device or app enrolment) should not travel together in one envelope or one email thread. Staggering them is a small friction that breaks the most common interception pattern.

6. Supervise the first login

   Have the new user sign in, change their password and test their token while you or a senior colleague is available. Our homepage login routine is written for exactly this moment — have them read it first. Confirm the new user can see precisely what their role should show: no more, no less.

7. Record what you did, the same day

   Log the date, the user created, the role and limits assigned, who approved the request, and the token's identifying details if it is a physical device. This register is dull to keep and priceless to have.

A word about tokens. Treat physical tokens like building keys: issued to a named person, recorded in the register, recovered on departure, and reported immediately when lost. For app-based tokens, the phone is the key — which means a staff member's personal phone now carries a business security function. Set expectations plainly at setup: the app stays on a phone with a screen lock, and if the phone is lost or replaced, the administrator hears about it the same day so the token can be dealt with properly.

Authorisation limits: small numbers, honestly set

Limits are the least glamorous setting in the platform and the one that decides how bad a bad day gets. An authoriser with an unlimited or casually huge limit converts any single mistake — or any single compromised account — into a business-threatening loss. An authoriser whose limit matches their real work converts the same event into an embarrassment and a phone call.

Set limits by looking at evidence, not vibes. Pull the last few months of payments the person actually authorised; the right limit usually sits a little above the normal maximum, with a process — a phone call to a second authoriser, a temporary lift approved by an owner — for the rare legitimate exception. Review limits whenever roles change, and be especially alert to limit creep: the temporary increase for the end-of-financial-year run that quietly became permanent. Where the platform requires two authorisers above a threshold, set that threshold deliberately too; a dual-authorisation line that sits above every payment you ever make is decorative, not protective. Finally, remember that limits interact with the payments workflow itself — our payments guide explains how creation, limits and authorisation fit together from the operator's side of the screen.

The onboarding checklist: a new starter's first week with access

Most access problems are born in the first week: a rushed setup, a password written on a sticky note "temporarily", a token left unregistered until the morning it is urgently needed. Run new starters through this checklist and the steady state mostly looks after itself.

• Identity and authority confirmed: you know who this person is, who approved their access, and what role they were approved for.
• Own credentials only: the new starter understands the login is theirs alone — never shared, never "borrowed", and that actions taken under it are attributed to them.
• Password set privately and stored properly: chosen by the user, not dictated by you, and kept in a password manager or other approved store — not in a notebook, spreadsheet or email to themselves.
• Token in hand and tested: physical token received and logged, or app token enrolled on their phone, and a test code successfully used during the supervised first login.
• The one-sentence security rule delivered: we only log in at nabconnect.nab.com.au, typed or from our own bookmark, and never from a link in a message. Our security guide gives you the longer version to share.
• Role boundaries explained in plain words: what they can see, what they can prepare, what they cannot release, and who to ask when the platform says no — so their first "access denied" is a shrug, not a workaround hunt.
• Register updated: user, role, limits, token and approver recorded the same day.

Schedule a two-minute follow-up a month later. Roles drift as people settle into real work — the new starter discovers they genuinely need one more account view, or never use half of what they were given. Adjusting early, deliberately and on the record is healthy administration. Discovering the drift during an incident review is not.

Departing staff: same-day removal is the whole job

If user creation is where security is designed, user removal is where it is proven. The pattern in real investigations is monotonous: a trusted employee leaves — sometimes happily, sometimes not — and their banking access outlives their employment by weeks or months because nobody owned the offboarding step. During that window the business is exposed to the one attacker it cannot vet: a person with legitimate credentials, real knowledge of payment routines, and no remaining loyalty. Whether or not anything ever happens, no insurer or auditor will look kindly on the gap.

The rule is simple to state: access ends on the last day of employment — ideally at the moment employment ends, and for involuntary departures, before the conversation if your HR process allows it. Treat banking access like the building key in the same checklist: collected, cancelled, confirmed. The removal itself should cover the full footprint, not just the login you remember creating:

• Disable or delete the user in the platform, rather than merely changing their password — a changed password can be reset by whoever still controls the recovery path.
• Recover the physical token, or have the app token deregistered, and record its return in the register.
• Check for the user's fingerprints elsewhere: payments they created that are still awaiting authorisation, templates or beneficiaries they maintained, reports scheduled to their email. Reassign or review each one — a pending payment created by a departed user deserves a second look before anyone releases it.
• Rotate anything shared they might know — office Wi-Fi, shared mailboxes, and (especially) any credentials that were informally shared despite policy. Their departure is your amnesty moment to fix the sharing.
• Confirm removal in writing to whoever manages your offboarding, and keep the confirmation with the register.

The same discipline applies, scaled down, to role changes and long absences. A staff member moving from finance to sales should lose finance access as their new role begins, not keep it "in case they help out". Parental leave, secondments and contractor engagements that pause are all reasons to suspend rather than leave live. Suspension is reversible in minutes; an incident is not reversible at all. And when a contractor's engagement ends, their access should end with it by default — renewal should be a decision, not an oversight. Contractors are the most commonly forgotten category in access reviews, precisely because no farewell morning tea marks their last day.

The quarterly access review: thirty minutes that prevent the worst meetings

Even well-run setups drift. Once a quarter — put it in the calendar now, recurring, with your name on it — export or list every user and walk the list with three questions. Does this person still work here, in this role? Anyone who fails that test is removed or adjusted on the spot. Does this role still match their job? Compare what they can do with what they actually do; shrink the gaps. Do the limits still match reality? Look for the temporary increases and the generous defaults, and pull them back to evidence.

Bring one more artefact to the review: the platform's own record of who authorised what over the quarter. You are not hunting for villains; you are looking for patterns — one authoriser releasing everything (where is the second pair of eyes?), approvals happening at odd hours (legitimate deadline, or something to ask about?), a creator whose payments are never queried (efficiency, or rubber-stamping?). Most quarters, the review produces a short list of tidy-ups and a warm feeling. Occasionally it catches the thing that would have become the story. Either way it creates the evidence that your business takes access seriously — evidence that matters to banks, insurers and auditors long before it matters to anyone else. If a user's login starts failing after a review tidy-up, our troubleshooting guide will help you sort out whether it is their credentials, their token, or a role change doing exactly what it was supposed to do.

Temporary staff, contractors and the access mistakes that repeat

Three situations produce a disproportionate share of setup errors. Temporary and contract staff need access with an expiry date attached, not an open-ended login justified by a short engagement. Decide the end date when you create the user, diarise it, and default to suspension on that date — renewal should require a fresh decision, because "the temp who stayed six months" is how unreviewed access accumulates. Keep their roles narrow: a temp doing data entry rarely needs authorisation rights, and never needs beneficiary-maintenance rights. Returning staff — from parental leave, secondment or a boomerang rehire — should get a fresh review rather than a reflexive reactivation of their old profile. Roles fossilise; the person returning to a changed job with an unchanged login inherits permissions designed for work they no longer do. Reactivate deliberately, adjust to the current role, and make them set a new password and re-confirm their token as part of the return. The founder's own access is the third trap. Owner-administrators commonly hold maximum rights under a login they also use for daily banking, which means the most powerful credentials in the business are also the most frequently typed — and therefore the most exposed to phishing. Consider separating the hats: a daily-use login with ordinary role rights for routine work, and administrator functions exercised deliberately rather than ambiently. It is a small friction that meaningfully shrinks the blast radius if the everyday login is ever compromised, and it models the least-privilege principle for the whole team better than any policy document.