Our last piece made the case that good customers fail identity checks because the data cannot see them. This one is about the opposite end of the same check: not whether we can find your customer, but what happens to their personal details once we have.
Every identity check makes a copy of someone's personal information. A name, a date of birth, an address get handed to a system, compared against something, and an answer comes back. The part that rarely makes the sales page is the part a security review actually cares about: after the answer comes back, where does that copy go, and who keeps it?
For a lot of the identity data supply chain, the honest answer is "somewhere, and we do." Details get written to a database so they can be looked at later. They get logged for debugging. They get cached to make the next check faster. Each of those is a reasonable engineering decision on its own. Stacked together, they mean a copy of your customer's identity now lives somewhere you do not control, for a length of time you did not set, protected by controls you have to take on trust.
We built IdentityPulse to not do that. The design goal was easy to say and hard to hold to: run the check, return the answer, and keep nothing that came from your customer.
The first thing to understand about how IdentityPulse handles data is that there are two completely different kinds of it moving through the platform, and they are treated in opposite ways.
The first kind is reference data. This is the identity dataset we match against: over 4 billion records across 43 countries, sourced through primary-source data partnerships. Reference data is meant to persist. It is encrypted at rest using AES-256 and held within designated Azure regions. We hold this data under licence, for matching purposes only. We do not originate it, we do not hand it to clients in raw form, and we do not act as a data broker or a credit bureau.
The second kind is the data your customer submits when you run a check. In the security paper we call these client verification payloads, which is procurement language for "the name, date of birth, and address you sent us to check." This kind of data is meant to disappear. It is received, matched, and then disposed of the moment the response goes back to you. It is never written to disk, to a database, to a log, to a backup, or to a cache.
That is the whole idea in one line. Reference data is built to last. Your customer's submitted data is built to vanish.
It helps to walk one check through, because the sequence is where the design shows up.
Your system sends an API request containing the identity attributes you want checked. That request arrives encrypted in transit over TLS 1.2 or 1.3; there is no unencrypted way to send it. The details are held in memory and matched against the reference data. The matching itself is deterministic and rule-based, tuned country by country with fixed thresholds. It is not probabilistic, and it is not an AI model making a judgement call. The same input produces the same result every time, for a reason we could write down.
What comes back is a match signal and one of three confidence tiers: Confirmed, Likely, or Possible. For a standard check, that is the entire response. No personal information is returned. We are telling you whether the person checks out, not handing you a file on them. And the moment that response leaves, the details you sent are disposed of.
There is no step in that sequence where a copy of your customer's data is quietly set aside for later.
"We delete it" is easy to say and easy to quietly not mean. So here is the precise version.
Client verification payloads are processed in memory and disposed of immediately after the response is returned. They are not persisted to any storage medium. Not to disk, not to a database, not to a log, not to a backup, not to a cache. This is not a setting you switch on or a premium tier. It is how the platform is built.
We do keep operational logs, and it is worth being exact about what is in them, because a vague claim here is worse than none. Our logs hold non-PII metadata only: timestamps, response codes, usage counters. The things an engineer needs to see that the system is healthy and to bill accurately. They do not contain the identity details your customer submitted, because those were never written down in the first place.
The reason this matters is not tidiness. It is what happens on the worst day.
Picture - though the case is unlikely - a storage breach against IdentityPulse: someone gets into where the data lives. What is there to find? Encrypted reference data, and nothing else. There is no record of which individuals were verified, no record of who asked, and no record of when. The single most sensitive thing in an identity verification flow, the running list of real people whose identities were checked and by whom, does not exist in our systems to be stolen, because we never assembled it.
This is what "structurally minimises data breach risk" actually means. Not a stronger lock on the vault. A design where, for the data your customer hands over, there is no vault to break into, because that data was never stored. The most effective defence against a data breach is making sure the sensitive data was never assembled in the first place.
For you, the practical effect is simple: plugging IdentityPulse in underneath your verification flow does not create a new place where your customers' identity data piles up. The check happens, and the data that made it possible is gone before you have finished reading the answer.
Being straight about the design means being straight about its edges.
Today, your customer's details are protected at every point around the match. Encrypted in transit on the way in. Matched in memory and never written down. Gone the instant the answer is returned. Reference data encrypted at rest the whole time. We describe this as privacy-preserving encryption: the data is exposed as little as the work allows, and it is never kept.
The direction we are working toward is extending that same protection through the match itself, by running it inside hardware-isolated enclaves so that data stays protected even during processing. This is active research for us, built on confidential-computing hardware. It is not how the platform runs today, and we would rather tell you where we are going than imply we are already there. The privacy story that stands right now does not depend on it: nothing your customer submits is ever stored, and a standard check hands back a match signal and a confidence tier, nothing more.
If your security team wants the full technical detail of how matching is implemented, including the cryptographic specifics, we share that documentation under NDA. The overview is public, on purpose. The deep internals are available to anyone evaluating us seriously.
There is exactly one case where more than a match signal comes back, and we would rather name it than let you find it in a contract.
It is called pre-fill enrichment. When a client has it enabled, a confirmed match can return verified identity fields, such as a name, address, or date of birth, alongside the match signal, so the client can auto-populate an onboarding form with data that has already been verified. The matching process is identical to a standard check. The only difference is what the response is permitted to contain.
Pre-fill is not on by default. It is activated per client under specific contractual terms that define exactly what the returned data can be used for, how long it can be kept, and how it must be handled. If a client has not signed up for it, their responses carry match signals and confidence tiers only, the same as everyone else. We mention this plainly, rather than bury it, because a "keep nothing" claim you cannot square with the one feature that returns data is not worth making.
Some of the strongest security statements are about what a system cannot do. These are things IdentityPulse does not have, by design, and each one closes off a category of risk.
There is no flat file transfer of reference data or verification results. There is no raw personal data in a standard response. There is no persistent storage of the payloads clients submit. There is no bulk data access endpoint and no batch extraction capability, so the platform cannot be turned into a pipe for draining the dataset. IdentityPulse does not perform credit reporting or furnish data to credit bureaus.
None of those are features waiting on a roadmap. They are absences we designed in, and they are as much a part of the security posture as anything we did build.
An identity check should tell you whether a person is who they say they are. It should not quietly become a second copy of that person's life, sitting in a system you do not run. IdentityPulse is built so the data source underneath your verification flow does the first job and refuses the second: it verifies the person, and it keeps nothing.
We wrote the whole thing down, in detail, for the procurement and security teams who need it. The encryption controls, the data processing model, the compliance alignment. It is a paper you can read right now. No gate, no form.
Read the full Security Overview →
Walk through the architecture, explore field-level coverage, and review the match quality rubrics in the Product Dashboard. No login required.
Talk to us about your 10,000 free credits →
Identity verification, rebuilt from the data layer up. Built in Australia. Supporting clients globally.
Australia
1300 946 432
USA
1888 907 7047
International
+61 3 9133 8777
We typically reply within one business day.
