How We Verify Bank Accounts Without Storing Bank Accounts

Business payment fraud is not a sophisticated attack. The most common form — Business Email Compromise — works like this: a fraudster intercepts or spoofs a supplier email, sends a convincing message asking you to update their banking details, and waits. If the payment goes to the new account before anyone checks, the money is gone. Recovery rates are low. The ABA estimates this costs Australian businesses over A$80 million per year, and that figure covers only reported losses.

The defence is also not sophisticated. It is a single question: does the bank account on this invoice actually belong to the business it claims to? If you could answer that question reliably, the attack fails.

The reason most businesses cannot answer it is that there is no easy way to look it up. Banks do not publish a directory of account holders. The ABR does not record payment details. There is no government register that maps BSB and account number to ABN. So when a supplier sends updated banking details, most accounts payable teams call the supplier to confirm — using a phone number from their records, not from the new email — and hope the call reaches the right person.

Gumshoe now offers a different option. Enter the BSB and account number from any invoice, and if that account is in our database, we return the ABN and entity it belongs to. You can verify the entity in full immediately — ABN status, GST registration, ASIC records, insolvency check, the lot — before the payment leaves your account.

The Obvious Problem With Building This

A searchable database of bank accounts is useful. It is also a target. If you build a table with rows that look like (account_number, bsb, business_name), you have created exactly the resource a fraudster needs to make their invoices look legitimate. A breach of that database would hand an attacker a ready-made directory of which account belongs to which business — the raw material for more convincing fraud, not less.

This is not a theoretical concern. It is the exact reason no such public directory has ever been built. The data is useful precisely because it is sensitive.

The design question is therefore: how do you build a lookup that answers the query "does this account belong to this business" without storing the account numbers that make the answer possible?

Cryptographic Hashing: The Standard Answer

The standard solution to "store something you can verify but cannot recover" is a one-way hash function. This is the same technique used to store passwords. You do not store the password — you store a transformed version of it that lets you verify a match without revealing the original.

The same principle applies here. Instead of storing account numbers, we store a hash of each account number. When a user queries an account, we hash their input and compare it to the stored hash. A match confirms the link without us ever needing to hold — or expose — the raw number.

But there is a catch specific to financial data that does not apply to passwords. Passwords are chosen from a vast space of possibilities. Bank account numbers are not. Australian account numbers are typically 6 to 9 digits. BSBs are 6 digits from a published list of roughly 10,000 values. An attacker with a hash and a known BSB could try every possible account number for that BSB — perhaps 10 million combinations — and identify matches in seconds on a standard laptop. A plain hash offers almost no protection against a determined attacker who has compromised the database.

HMAC: The Key That Makes It Work

The solution is a keyed hash — specifically HMAC-SHA256. HMAC (Hash-based Message Authentication Code) takes two inputs: the data you want to hash, and a secret key. The output is a hash that is cryptographically bound to the key. Without the key, you cannot verify or reproduce any hash in the database, even if you know the account number you are looking for.

The key lives only on Gumshoe's servers, in an environment variable that is never stored in the database, never transmitted to clients, and never logged. An attacker who breaches only the database has a collection of 64-character strings that are computationally worthless without the key. An attacker who also breaches the key has a more serious problem on their hands than account number enumeration.

This is a well-understood technique. It is the same principle behind HMAC-based token validation in OAuth, webhook signature verification, and password-equivalent credential storage. We are applying it to a domain — financial identifiers — where it has historically been underused.

What We Store, and What We Do Not

For each account in our database:

The BSB is stored in full because it is already public. The Australian Payments Network publishes the complete BSB register — every financial institution and branch in the country — and Gumshoe serves it as part of every lookup. Knowing that BSB 062-000 is the Commonwealth Bank's Martin Place Sydney branch reveals nothing about any individual account holder.

The last 4 digits are stored for display purposes only. They let us show you "account ending in 1234" so you can confirm you entered the right number. Four digits in isolation are insufficient to identify or transact on any account.

How the Database Is Built

Unlike the BSB register, which is maintained by the Australian Payments Network, there is no authoritative public source for account-to-business mappings. We cannot buy this data, scrape it, or obtain it from any government register. We build it from the ground up, one submission at a time, from Gumshoe users who submit account details from invoices they have received.

When a user cannot find a match for an account they have looked up, they can submit a claim: "this account, on an invoice I received, belongs to this ABN." That claim is hashed and stored immediately. Future users looking up the same account will find the match.

When multiple users independently submit the same account-to-ABN link, the corroboration count increases. A match with 10 independent corroborations from different users is more reliable than a match with one. Businesses can also self-declare their own account details, which we show with a distinct label — the business has direct knowledge of their own account in a way that an invoice recipient does not.

The Privacy Act Position

Australian Privacy Principle 3 requires that organisations only collect personal information that is reasonably necessary for their functions. APP 11 requires that it be protected from unauthorised access. The question for any service handling bank account details is whether those details constitute "personal information" — information about an identifiable individual — and if so, how that obligation is met.

For sole traders, bank account details can identify an individual and are reasonably considered personal information. For companies, the position is less clear — the Privacy Act applies to individuals, not corporations — but the practical risk of a breached database of business account numbers is significant regardless of the legal classification.

Our design addresses both. The HMAC hash is not the account number. It cannot identify any individual, cannot be used for any financial transaction, and cannot be reversed without the key. The Office of the Australian Information Commissioner's guidance on de-identification holds that information is de-identified when it is no longer reasonably capable of identifying an individual. A 64-character HMAC hash, in isolation, meets that standard.

This is not a legal workaround — it is a genuine privacy architecture. The reason we do not store account numbers is not because we have structured our way around an obligation. It is because there is no reason to store them, and every reason not to.

What We Cannot Do

Transparency matters here. The bank account lookup is a useful tool, but its limitations are real and should be understood before you rely on it.

We have no connection to any bank's systems. We cannot confirm that a business actually holds a given account. We can only tell you that another Gumshoe user received an invoice from that account and linked it to a particular ABN. That user may have been correct. They may also have received a fraudulent invoice themselves and submitted a fraudulent link in good faith.

The database reflects historical submissions, not current state. Businesses change bank accounts. A match that was correct eighteen months ago may no longer be. We show submission dates and corroboration counts so you can assess freshness, but we recommend confirming any large payment change directly with your supplier via a phone number you already hold — not via a reply to the invoice email.

Absence of a match is not a red flag. The database is built from user submissions. A legitimate business that none of our users have previously invoiced will have no entry. A missing match means the account is not yet in our database — it does not mean the account is suspicious.

The Bigger Picture

Payment fraud is a solvable problem. Not by chasing down individual fraudsters, but by making the verification cheap enough that it happens as a matter of routine before every significant payment. If confirming that a bank account belongs to the business on the invoice takes thirty seconds and is built into the standard accounts payable workflow, the economic case for invoice fraud collapses. The attack succeeds only when the check does not happen.

That is what this feature is for. Not a forensic investigation tool — a friction-free sanity check that sits at the point where fraud most often succeeds: the moment you update a supplier's payment details.

The lookup is available now on the Gumshoe search page. Click "Search by bank account" below the main search bar, enter the BSB and account number, and see what we know.

Uncommon Insights

The Australian Transaction Reports and Analysis Centre (AUSTRAC) requires businesses to verify the identity of their customers and maintain accurate records of their transactions. However, when it comes to verifying bank account ownership, the Anti-Money Laundering and Counter-Terrorism Financing Act 2006 (AML/CTF Act) does not provide explicit guidance. To navigate this regulatory grey area, our solution relies on the ATO's guidance on electronic authentication, which emphasizes the importance of using secure and reliable methods to verify identities and transactions.

ASIC's Regulatory Guide 221: Facilitating online financial services discloses that online verification of bank account ownership is permissible, provided it meets certain security and authentication standards. Our use of cryptographic hashing to verify account ownership without storing sensitive information aligns with these guidelines, ensuring that our solution is both secure and compliant with regulatory requirements.

Interestingly, the ATO's own systems use a similar approach to verify the identity of taxpayers and their representatives. The ATO's Practitioner Lodgment Service (PLS) uses a combination of authentication and authorization protocols to ensure that only authorized representatives can access taxpayer information. Our solution draws inspiration from these protocols to provide a secure and reliable way to verify bank account ownership.

While the Corporations Act 2001 (Cth) does not explicitly address the verification of bank account ownership, section 254T requires companies to maintain accurate records of their transactions. Our solution helps companies meet this requirement by providing a secure and reliable way to verify the ownership of bank accounts, reducing the risk of payment fraud and ensuring compliance with regulatory requirements.