Screening

Screening is the BNDRY feature that checks an entity against external risk databases — sanctions lists, politically exposed person (PEP) lists, adverse media, and related datasets — and surfaces any matches against the customer's record. It runs as part of onboarding, on demand from a reviewer, and on a periodic basis for ongoing monitoring, with the results recorded as an activity log against the entity.

Screening sits inside the wider risk surface in BNDRY: matches feed into the customer file, can inform a risk rating, and are the trigger for human review when something needs a closer look.

Why screening exists

Australian reporting entities are required to identify customers and counterparties who appear on sanctions lists, hold politically exposed roles, or attract significant adverse media coverage — both at onboarding and throughout the customer relationship. Screening operationalises that obligation. Rather than relying on a reviewer to search public sources for each customer, BNDRY runs the query against a screening provider's curated dataset, returns the matches with supporting evidence, and keeps the result on file for audit.

Running screening through BNDRY also gives compliance teams a consistent, repeatable query: the same inputs against the same provider produce results that can be re-screened, compared over time, and explained in a regulator review.

Key properties and sub-types

A screening result in BNDRY captures four things: the provider, the query that was submitted, the matches that came back, and the evidence supporting each match.

• Provider — the third party that produced the result. BNDRY supports several screening providers depending on what's being checked, PEP and sanctions and identity verification. The provider is recorded on every result so a reviewer can trace where a match came from.
• Query context — a snapshot of what was searched: the name (structured or full), date of birth where applicable, country filters, and match tuning such as fuzziness or exact-match. The query is kept alongside the result so any later review can see exactly what was screened, not just what came back.
• Matches — the candidate records returned by the provider, ordered by confidence score. Each match carries a primary name, the alias variant that triggered the hit, dataset tags (PEP, PEP-current, PEP-former, PEP-linked, sanctions-current, sanctions-former, reputational risk, insolvency, disqualified director, regulatory enforcement, state-owned enterprise, and others), structured details such as positions held, aliases, addresses, identifiers, and known associates.
• Evidence — supporting documents and source references attached to a match, with credibility, language, capture and publication timestamps, and links back to the original source where the provider allows. PEP entries, sanction events, and adverse-media events reference evidence by ID so a reviewer can follow the trail from a single classification tag back to a specific source.

Screening covers individual entities and business entities; the shape of the result differs (a business match carries entity types, activities, regulatory enforcement entries) but the surrounding model is the same.

How screening relates

Screening targets an Entity — individual, company, or trust — and produces matches that are stored on the entity's record. Each screening run is recorded as an Activity log, which is the audit trail of who ran what against which provider and when. Hits surface on the entity for reviewer attention and feed into Risk rating through scoring rules — a confirmed sanctions match typically pushes a customer into a higher band. Screening runs as part of Onboarding and is re-run during Ongoing customer due diligence; identity-document checks at onboarding are handled by the related Identity verification feature rather than by screening itself.