Activities

An activity is BNDRY's record of something that has been done to or for an entity. Each entity in BNDRY (an individual, business, or trust) carries a timeline of activities — verifications run, screenings completed, risk ratings produced, reports lodged, forms created, and any custom events your operations team chooses to log. Activities live alongside the entity they relate to and, optionally, the workspace the work was performed in.

Why activities exist

Compliance work is judged by what you can show, not by what you remember. Every meaningful step in an entity's life cycle — a PEP and sanctions check, an ID document check, a risk rating, a suspicious matter report — produces an activity, and that activity becomes the audit trail your AML programme, your auditors, and AUSTRAC rely on. Activities also give the people working on a case a single shared timeline: who screened this customer last week, what the result was, and whether anything needs following up.

Because activities are append-only and tied to the entity, they hold the line between automated platform work (a screening job finishing, a verification completing) and operator-driven work (uploading a report, logging a customer interaction). Both end up on the same timeline.

Key properties and sub-types

Every activity carries a small, fixed set of properties, plus a type-specific payload that holds the detail of what actually happened.

• Type — what kind of activity it is. Current types are PEP and sanctions, document verification, identity check, risk rating, KYB profile, identity research, form created, unusual activity report, suspicious matter report, and custom.
• Source — who or what produced it. This may be BNDRY itself, an integrated provider, or a customer-side action.
• Entities — the entity or entities the activity relates to. An activity must reference at least one entity, and may reference several.
• Workspace — the workspace the activity was performed in, when applicable.
• Occurred time — when the activity took place. For unusual activity and suspicious matter reports this is the incident date; for custom activities it is the time the operator records; otherwise it defaults to when the activity was created.
• Payload — the type-specific body. A risk rating activity carries the rating result; a PEP and sanctions activity carries the screening result; a custom activity carries free-form comments, an activity log type, optional file attachments, and the date the incident occurred.

The custom type is worth singling out because it is the one you control. Each tenant can define its own activity log types — for example, customer sign-in, welcome call completed, EDD review — and operators choose from those when they log a custom activity. Everything else (screenings, verifications, reports) is created by BNDRY or the relevant integration as part of normal processing.

How activities relate

An activity always attaches to one or more entities and, where relevant, to a workspace. It is distinct from an event, which is the platform's lower-level system signal used for webhooks and integrations: events tell external systems that something happened; activities tell people what was done. Many activities are produced as the by-product of finishing a piece of automated work — for example, completing a verification job or a screening job creates the corresponding activity on the timeline. Reports filed against an entity (unusual activity reports, suspicious matter reports) are also surfaced as activities so the entity's history is complete in one place.