2026-07-06

How to detect when a business you onboarded gets deregistered, sanctioned, or goes insolvent

Verifying a business at onboarding tells you it was clear then. It does not tell you anything about now. Businesses get deregistered, turn up on a sanctions list, or have an insolvency notice filed against them long after you signed them up as a customer, supplier, or borrower. Here is how to get told the moment that happens, instead of finding out months later.

The ongoing-risk problem

Point-in-time verification is a snapshot. Risk is continuous. The gap between "verified at onboarding" and "still safe today" is exactly where losses happen: a supplier deregisters and stops being a legal entity, a counterparty appears on a sanctions list, a borrower's company enters external administration. If you only check once, you find out about these the hard way, from a bounced payment or a compliance audit, not from your own systems.

The signals worth watching

Not every change matters equally, but a few are consistently the ones that predict loss:

Deregistration (ASIC): the company stops existing as a legal entity. A sanctions hit (DFAT): the entity or a closely matched name appears on the sanctions consolidated list, always a possible-match, never treated as confirmed. An insolvency notice (ASIC insolvency notices): an external administrator has been appointed. A licensing change (ASIC AFS or credit licensee registers): a licence is suspended or cancelled. A charity-status change (ACNC): registration status changes for a charity you deal with. For bankruptcy specifically, the API surfaces a petition filed, a distress signal that someone has applied to the court, never adjudicated bankruptcy status. That adjudicated register is paid and out of scope; a petition is the free, earlier signal.

How to set up monitoring with AUO

Subscribe to an entity once and it takes care of the watching. When one of the events above happens, your server receives an HMAC-signed, replay-safe webhook.

curl https://api.auo.com.au/v1/watch \
  -H "Authorization: Bearer auo_sk_live_your_key" \
  -H "Content-Type: application/json" \
  -d '{"events": ["deregistration", "sanctions_match", "external_administration"],
       "webhook_url": "https://example.com/hooks/auo",
       "entities": ["46008583542"]}'

When a watched event fires, your endpoint receives a payload like this, with the source register and the date the change was observed attached to it:

{
  "event": "deregistration",
  "entity": { "identifier": "46008583542", "id_type": "abn" },
  "source": "asic-companies",
  "as_of": "2026-07-04",
  "detail": {
    "company_status": "Deregistered"
  }
}

If your endpoint is down or you would rather not run a webhook receiver, poll GET /v1/entity/{id}/changes instead. Nothing is lost either way: every delivery is retried and every change is queryable.

Point-in-time vs transitions

/resolve tells you the current state of an entity. /watch tells you the moment that state changes. They read from the same red flag sources, so what you see in a resolve response and what fires a webhook event are always the same list: deregistration, sanctions, insolvency, licensing, charity status. One is a snapshot, the other is a subscription to the same facts over time.

Try it free

The full API, including /watch, works against a sandbox at no cost. Wire up your webhook handler against test events, then flip to live data by upgrading.

Get a free sandbox key