Tags

A tag in BNDRY is a labelled marker applied to an entity — an individual or a company — that captures something worth knowing at a glance. Tags surface on the entity record, can be filtered on in lists, and form part of the audit trail. They live alongside risk ratings and screening results as part of what your team sees the moment they open a record.

Tags have two sides to them. On one side is the catalogue: the tag types and tag definitions that exist in your tenant, with their labels, descriptions, and display colours. On the other side is the application: an individual tag attached to a specific entity, with a timestamp recording when it was added. Both sides matter, and the platform exposes them as separate resources so they can be managed independently.

Why tags exist

Regulated businesses need a fast, consistent way to flag things about a customer or counterparty: "PEP match," "manual review needed," "high net worth," "screening hit unresolved." Free-text notes are easy to write but hard to act on at scale — they don't filter, they don't aggregate, and two staff members will phrase the same thing five different ways.

Tags solve that by turning those flags into structured, controlled values. The catalogue determines which tags are even available; the application records who's been tagged with what and when. The result is a record that's both human-readable and queryable — useful for the analyst opening a single file, useful for the operations lead reporting on the population, and useful for the automation that decides what to do next.

Key properties and sub-types

Tags are organised in a two-level structure, plus the act of applying one:

• Tag type — a category such as "screening" or "risk level." Each tag type has a display name, an optional description, and a flag indicating whether it's read-only (managed by the platform) or editable by the tenant.
• Tag definition — a specific value within a tag type, such as "PEP match" or "sanctions hit" within the "screening" tag type. Each definition has a display name, a description, and a hex colour code that the UI uses when the tag is rendered.
• Tag — the application of a tag definition to a specific entity. Each applied tag carries a reference to the definition it instantiates and a timestamp of when it was attached, so the entity's tag history is fully ordered.

Tags are added and removed through the platform's tag operations — addition is idempotent, so applying the same tag twice is a no-op rather than an error, and removal of a tag that isn't present is also a no-op. Both individuals and companies can be tagged, with the same tag-definition catalogue available across both entity types.

Some tag types are read-only and managed by the platform itself — for example, tags that the platform applies as a result of a screening or risk-rating outcome. Read-only tag types can still be searched and filtered on, but the catalogue can't be edited from the tenant configuration.

How tags relate

Tags are a downstream artefact of nearly everything else in BNDRY. An automation may apply a tag when it finishes; policy may decide which tag to apply based on a screening or risk-rating outcome; the tag catalogue itself is shaped by the policy decisions your tenant has made about what's worth tracking.

Tags also show up in events — adding or removing a tag is an audit-relevant change — and in any list view where filtering by category matters. When a tag is added by an automation, the automation execution and the tag application are linked through the entity they both refer to, so the "why" is traceable from either direction.