How do NDIS providers prove who submitted a claim?

Why is the NDIA now asking who made the claim?

Because the scheme was defrauded. The NDIS Amendment (Integrity and Safeguarding) Act 2026 gave the CEO power to demand evidence before paying, and the obligation attaches to the person who made the claim.

Identity became the control surface for scheme integrity because the scheme was targeted by organised criminal activity, and the response was to make identity verifiable wherever money moves. The NDIA's Fraud Fusion Taskforce states this as a design principle for government payment programmes: "Embed verified identity, authentication, and authorisation into transactions, registrations, and payments to ensure individuals and entities can be consistently recognised and trusted across systems." The wording repays attention. Individuals and entities. Across systems.

The NDIS Amendment (Integrity and Safeguarding) Act 2026 received Royal Assent on 8 April 2026, and Schedule 2, Part 2 commenced on 6 May 2026. Subsection 45(3B) lets the CEO require, by written notice, a person who makes a claim to give further information or documents in relation to it. Subsection 45(3C) requires that notice to specify a period of not less than 14 days. Subsection 45(3A) then stops the Agency paying where that person has not given the information within the period specified.

Read those together and the drafting is doing something specific. The obligation attaches to the person who makes the claim, and the consequence for silence is non-payment. None of this arrived because providers under-invested. It arrived because the scheme was defrauded, and the Commonwealth is closing the routes that allowed it.

Where does identity assurance stop between your systems and the NDIA's?

At the boundary. Portal users are verified through myID and RAM. Claims sent through the API authenticate on a PRODA business-to-business credential, which identifies your organisation and not the person using it.

The portal channel is where the uplift happened. From 10 November 2025, PRODA access to NDIS provider portals was discontinued and staff moved to myID with the Relationship Authorisation Manager. Every staff member needs a myID at Standard strength, which verifies information against issuer records for at least two Australian identity documents. Principal authorities need Strong strength, which adds a facial verification step. When a person keys a claim into the portal, the Commonwealth knows who they are to a documented assurance level.

The API channel is where it does not. A provider integrating directly, or through an approved software developer or aggregator, authenticates using a PRODA business-to-business device. A person logs into PRODA using their own verified identity credential, registers a device, and obtains a credential. That credential is then configured into the provider's software, where it operates on behalf of the organisation.

The verification was real. It happened once, to one person, at one moment in time. Every claim and every report submitted afterwards inherits the trust of that historical login. The credential does not know who is using it. It does not lapse when that person's worker screening expires, and it does not lapse when they leave. The Australian Taxation Office documents the same Commonwealth model in plain terms: machine credentials are not individual authentication, they carry the business entity's identity, and responsibility for their use sits with the business rather than a user.

Services Australia's guidance on managing business-to-business devices in PRODA was last updated on 17 November 2022. There is no published deprecation notice and no announced transition to myID or RAM. The individual path moved. The machine path did not.

Who actually touched that claim?

At least two people, and the Agency can name neither. Someone created the service record, someone or something transmitted it, and the credential that carried it identifies only the organisation.

A support worker delivers a service and a record is created. Sometimes by that worker, sometimes by a coordinator entering it on their behalf, sometimes by an administrator working from a paper timesheet. That person may have signed into a named account, or into a shared login that three people use because it was easier to set up that way in a service with high turnover. Later the claim is transmitted, either by someone pressing a button or by a scheduled process running overnight. That is a second person, or no person at all.

The same is true of everything else moving through that channel: service bookings, quotations, supporting documents. The API carries the reporting as well as the payments, so this isn't confined to money. It runs through the record that is supposed to substantiate the money.

Now put the substantiation request against that. The NDIA's own record-keeping guidance tells providers to hold invoices, support logs, rosters, case notes and service agreements. Every one of those is a per-worker, per-shift artefact. The Agency is asking a question about individuals, and the provider is answering it from systems that only ever recorded an organisation.

There is a second-order version of this that's easy to miss. Substantiation can be sought against claims already paid, which means attribution has to be retained and retrievable rather than merely captured. A system that records which user created an entry but overwrites that log, or holds it for ninety days, can't answer a question about a claim from two years ago.

How do you know whether this is your problem?

Check which of three routes your claims take: portal only, direct API integration, or an aggregator. The aggregator case is the most exposed and the least visible, because the arrangement may never have crossed your desk.

If you claim only through the myplace provider portal, the submitter question is closed at the boundary. What isn't closed is everything behind it: whether the service record the claim rests on was created under a named account or a shared login. Portal assurance is also only as good as your account hygiene. One RAM-authorised account that four rostering staff share is nominally correct and evidentially worthless.

If you integrate directly, the credential is yours. Your organisation signed the NDIA API Terms and Conditions, and clause 2.6 requires you to take reasonable steps to ensure that nobody other than you and your personnel accesses the API with your credentials. You can find out today who holds it and when it was issued.

If you integrate indirectly through an aggregator, this is the hardest case. Your software partner submitted the application on your behalf, so the arrangement may never have crossed your desk. The Terms are still with you as the registered provider, and clause 4.3 makes you responsible for notifying the Agency of breaches by you, your personnel, your end users or any other person. Whether you can establish which of your staff triggered a given submission depends entirely on what your software partner logs and how long they keep it.

One thing worth checking against all three routes. The advice already circulating in the sector, reconcile your worker screening register against who holds current system access, is worth doing and doesn't reach this. A business-to-business credential is not a user account. It won't appear in that reconciliation. A provider can complete that exercise perfectly and still be submitting every claim through a credential obtained by somebody who left eighteen months ago.

Why has nobody closed this gap?

Because it sits at a seam. Government can't regulate inside your systems quickly, the technical standard is still in draft at the IETF, and nobody owns the join between the two.

Government can regulate the systems private organisations use, but doing so is slow. It requires policy that doesn't yet exist, consultation across a software market serving more than 15,000 active registered providers, and funding that hasn't been identified. The Commonwealth sequenced sensibly and raised assurance at the points it directly controls, which was the part it could actually move.

The standards are also young. The technical problem, letting a receiving domain know which human initiated an action that originated inside another organisation's systems, has an answer in draft rather than in force. The IETF's identity chaining specification, built on the OAuth 2.0 Token Exchange standard published in January 2020, reached version 17 on 19 July 2026 and is approved and awaiting publication. No Australian government standard adopts it.

Providers adopted integrations because they cut administrative load and improve cash flow, which is good for participants and good for the workers waiting to be paid. Software vendors built to the specification the Commonwealth published. Nobody in this chain made a poor decision. The gap sits at the seam between two systems of accountability, and seams are nobody's job by definition.

Which is the part worth sitting with. The NDIA doesn't need to regulate your software to decline a claim it can't have substantiated. That power exists now, it costs the Agency nothing to use, and it doesn't require anyone to have done anything wrong.

What can you actually do about it?

Make your own systems the record of who did what. Verify people at onboarding, use phishing-resistant authentication, bind attribution to every record and retain it, and give the B2B credential a named custodian.

You can't change how the channel authenticates. What you can do is make your own systems the record of who did what, so you can answer from your side even though the channel never carried it. In practice that means mirroring, inside your organisation, what the Commonwealth has built at its own front door.

Verify people when they join and remove them when they leave. The current Australian benchmark is the Digital ID (Accreditation) Rules 2024 made under the Digital ID Act 2024, which set identity proofing levels from IP1 to IP3. Standard, IP2, requires verification against at least two Australian identity documents. Strong, IP3, adds biometric matching. Worth noting for anyone whose internal standards still cite it: the Trusted Digital Identity Framework was a non-statutory pilot programme and has been superseded by that statutory scheme, regulated by the ACCC as Digital ID Regulator with the OAIC covering privacy.

Use phishing-resistant authentication. In practice that means device-bound passkeys or certificate-based credentials, where a biometric check on the device releases a credential held there, rather than a face being matched centrally at every login. The distinction matters legally as well as technically. Biometric information is sensitive information under the Privacy Act 1988, so a provider that collects and retains facial images takes on collection, use, retention and destruction obligations under the Australian Privacy Principles that most haven't planned for.

Capture attribution and keep it. Every record capable of supporting a claim should carry the named person who created it, cross-referenceable to that verified identity, and be retained for at least as long as substantiation can be sought against the claim it supports. Shared logins defeat all of this. A named account is the difference between an audit trail and a list of events.

None of this needs to be a programme for a smaller provider. Most already licence identity capability inside the productivity platform they pay for every month and aren't using it. Named accounts instead of shared logins, phishing-resistant multi-factor turned on, and a case management system configured to record which user created each entry will carry a small provider a long way. The task isn't to build identity assurance from nothing. It's to stop discarding the assurance you're already paying for.

What does success look like for NDIS technology leaders?

You can answer the question when it's asked. A substantiation request arrives and you produce the service record, the plan reference, and the named person who created it, inside the period specified.

The Auditor-General found the NDIA manually reviewed 0.4 per cent of claims by dollar value before payment across the first half of 2024-25, and cancelled 53.7 per cent by value of the claims it did review. The odds of any single claim being looked at are low. The consequence when one is looked at is not, and the integrity workforce behind those reviews grew from roughly 100 people in 2020-21 to over 800.

The gap between what the NDIA can now ask and what a provider system can currently answer isn't a failure of anyone in the delivery chain. It's a seam, and closing it from your side is both achievable and squarely within your control. The fastest way to find out where you stand is to go looking for a name in an audit trail and see what comes back.