Custom properties: model your own data in Bits

Every compliance program has data that no standard schema anticipates: source of funds categories, an internal segment code, a merchant category you want on every card transaction, the countries a company actually operates in. Standard KYC and KYB fields cover identity, ownership, and contact details well. They say nothing about how your business classifies its customers.

A custom property is a field you define yourself. It has a name, a type that says what a value can be, and a place it belongs: individuals, organizations, or transactions. It is typically something you collect during onboarding or an investigation and want to keep with the record, so it is there the next time anyone opens that customer or that payment. A few practical examples: a declared source of funds picked from a fixed list, an expected monthly volume as a number, a product or segment code for internal routing, the merchant category on card transactions, or a note on why a customer was accepted despite a higher risk score.

Once a field is structured, it stops being a note and becomes data. You can filter a customer list on it, show it as a column, translate its label for colleagues in another market, and feed it into the same rules and workflows that run on the standard fields. Custom properties are how you add those fields to Bits and use them where the standard fields work. The rest of this post walks through how.

Types first, then properties

Under Properties in the dashboard you manage two things. Types define what a value can be: a list of named values, a country or a set of countries, free text, or a number. A values type carries display names per language, so the same property reads naturally in English, Swedish, Finnish, Danish, and Norwegian.

Properties attach a type to a resource. A property applies to individuals, organizations, or financial transactions, and can allow one value or several. Transaction properties can be scoped further by transaction type and by the debtor’s and creditor’s countries, so a field only appears on the transactions where it makes sense.

Where they show up

• Entity pages: custom properties are shown and edited on individual and organization profiles.

• Entity lists: add them as columns and filter on them with the advanced filters.

• Transactions: a custom properties section on the transaction detail, editable in the same session as the standard fields.

• Procedures: use a custom property as a condition field. A values property whose only values are TRUE and FALSE behaves as a boolean.

• Onboarding workflows: a Set entity property step writes or clears a custom property during onboarding.

• Ongoing due diligence: custom property columns in the ODD views.

The point is not storage. It is that a field you define on Monday can drive a rule on Tuesday.

Why this matters for compliance

Risk appetite is specific to your business. Modeling that specificity as structured, typed data instead of free-form notes keeps it filterable, auditable, and usable by automation, and it keeps every analyst reading the same label in their own language.

Want to see it in action? Reach out to learn how Bits Technology can streamline your compliance operations.