What are schemas used for?
Schemas have four purposes:
Data validation: ensuring the data matches the expected format and values before being accepted into the system.
Search and Alert filtering: without specifying the field names in schemas search won’t work and you won’t able to filter our Alerts based on Person and Transaction data.
Human readable names: they are used to present Person or Transaction fields in a more descriptive way (e.g. “Date of Birth” is more descriptive than “dob”). This feature makes data fields more understandable for your AML team.
Ordering: Schemas dictate the location of the data item on the profile page. For example, the schema example below has the phone number as the first item. After adding some schema fields you will be able to control their order. To change the order, click and drag any field in the table and drop it where you want it to be. Field that is located on top will be displayed first.
How to add or edit fields in Schemas
To add or edit existing schema, navigate to the Configuration → General → Schemas.
User roles which can see and edit Schemas: ANALYST, CUSTOMER_ADMIN, IT_ADMIN.
Select whether you want to add or edit Person or Transaction Schemas:
Click the New field button to open a modal window with the following fields:
Display name: enter a descriptive name for the field (e.g., Date of Birth). Display names must be unique (child field names of an OBJECT are only compared to other child fields within the same parent field).
Field name: add the name of the attribute (e.g., dob, first_name). Field names must be unique and can only contain letters, numbers or underscores.
Input type: select the type of the attribute. There are five types of attributes: STRING, NUMBER, DATETIME, OBJECT and ENUM. Read more about each type below.
Array: tick array option if several values for the same data field should be allowed, e.g., sending several industries or bank accounts.
NB! Array option is only available for Person schemas!
When sending array fields via API, they always must be wrapped in
[]brackets.When uploading data manually using CSV file, array fields must be uploaded using Person relation data type.
Field options: you can select other field settings. Read more about each option at the end of this article.
You can add schemas anytime by clicking ••• → Edit or +New field.
❗️ Important Notice: be very careful when making changes to schemas that are already in use or adding new ones. Editing the type of an input field, marking a field as required that is not consistently populated, or introducing new schemas can disrupt data upload and lead to errors.
It’s recommended to review and understand the implications of any changes thoroughly before applying them. If the current schema setup is working correctly, consider whether the edits or additions are necessary to avoid unintended disruptions. If unsure, please contact Salv support.
💡 Suggestion: before applying changes to your live environment, test the updated or new schemas in a demo environment first. This helps ensure that your changes work as expected and do not cause any issues with data upload or processing.
Different input types
Data that you send our way is validated against Schemas that you set - if data models do not match, there is an error and data is not accepted.
Additionally, field type affects how attribute value will be presented and displayed.
STRING
The STRING type displays attribute values as plain text without any modification. It is the default attribute type and is ideal for general text data. Use STRING for fields such as names, addresses, and other textual information.
Examples:
first_name: "John"last_name: “Doe”street_address: "2311 North Los Robles Avenue"country: "EE"
Note: If you are unsure which type to select, STRING is a safe default choice.
NUMBER
The NUMBER type presents attribute values as numerical data. This type is suitable for any data that should be interpreted as a number, such as currency amounts, quantities, or identifiers. The NUMBER type aligns numbers to the right in tables, making them easier to read and compare.
Examples:
amount: 1000.00expected_monthly_turnover: 50000identifier: 12345
Formatting Tips:
Ensure the data sent matches the expected numerical format.
Use this type for fields that require mathematical operations or comparisons in Scenarios or Rules.
We do allow NUMBER type sent as STRING.
DATETIME
The DATETIME type is used for date and time data formatted according to the ISO 8601 standard. This type ensures that dates and times are consistently formatted and easily comparable.
The relevant data point must contain at least year, month, and day separated by a dash (yyyy-MM-dd), and followed by the hours, minutes, and seconds separated by the colon (HH:mm:ss). You can optionally use the letter T or a space to separate date from the time. In addition, you can optionally add milliseconds (between 1-6 digits) and timezone specifier according to the standard.
❗ DATETIME field must include at least the year, month, and day (yyyy-MM-dd).
An example of a valid DATETIME value:
2022-01-01T12:59:59
2022-01-01T12:59:59.999999
2022-01-01 12:59:59
2022-01-01 12:59:59Z
2022-01-01 12:59:59+02:00
2022-01-01
💡 When displaying values for a DATETIME type field, Salv uses your browser or system settings to determine the appropriate format.
OBJECT
It's used to display attributes having JSON data as a value.
An example of such data (more examples in API documentation):
When OBJECT type is selected, system prompts you to add child fields.
For each child field, you must add a display name, field name, select its type and mark whether it’s required.
Note: If an OBJECT data field is not marked as required, but a child field within it is marked as required, data will be accepted if the OBJECT field is not present. However, if the OBJECT field is present, the required child field must also be provided.
Child fields are also subject to data validation.
For array objects, an
idkey is strongly recommended to be present. Anidis needed to support updates. If anidis missing, then this item in an array cannot be updated.
👤 OBJECT is only available for Person schemas.
🔍 Currently searching and filtering alerts by OBJECT child fields is not available.
Display of OBJECT input type
In data uploads, we often refer to it as nested or complex data. This data can be sent via API or uploaded manually, just like any other data. If you’re unsure what complex/nested/person relation data is, click here.
When an OBJECT input type (or nested/complex data) is used, it is depicted on the person page as follows:
The parent field is shown on the person page.
The first three child fields are automatically displayed next to the parent field.
The rest of the child fields become visible when you hover over the blue dotted text.
You can change the order of the fields within the OBJECT field by clicking Edit and then dragging and dropping the child fields to your desired order.
ENUM
ENUM type represents a group of defined values.
For example, you only want to have LOW, MEDIUM or HIGH values for risk_level data field, and if any other value is sent, you want to receive an error. This type is great when you know exactly what values are being sent and want to make sure no other values slip through.
💡 An example use case - your client chooses industry from a dropdown during onboarding.
When ENUM type is selected, system prompts you to add available field values - field options.
If Array option is ticked, several values from the available options are accepted, e.g. several industries.
❗️ ENUM field options are case sensitive, i.e. if you add “AGRICULTURE” as an option, but send “Agriculture” - data will not be accepted.
An example of ENUM input type with several field options
Field options
Quick link to search page
Quick link to search page toggle is used to link specific field to search page in UI. Linked field's link will direct one to search page where field will be used as a filter to search by.
An example, where Company Activity field is set to link to search page - clicking on the activity, in this case Art dealer, will automatically link to Search page where field and value are automatically pre-filled, showing you all Persons where Company Activity is Art dealer.
Clicking on the blue value:
Forwards you to an automatically pre-filled search:
Field is required
When a field is marked as required, it means that data for this field must be provided for each entry. If the data is not provided, the system will return an error, and the entry will not be accepted.
Marking a field as required ensures that essential data is always captured and available for processing. However, be cautious when marking fields as required, especially if the data is not always available or applicable to all entries, as this can disrupt data upload and processing.
Field is visible
When a field is marked as visible, it will appear on the Person or Transaction pages, as well as on pages related to Alerts. If the field is not selected, it will not be displayed anywhere.
This option is useful for fields that are important for Monitoring or Screening configurations but do not need to be visible to analysts. By deselecting such fields, you can declutter the interface while still using these fields in the configuration.
Field is searchable
When a field is marked as searchable, it becomes available in the Person or Transaction search. This allows you to filter records using this field in the Search page.
❗️Once enabled, the field’s name and type can no longer be edited. This is because the search logic (e.g. operators like “is after” or “is higher than”) is based on the field type, and changing it would require reindexing your entire dataset.
If you do need to change the field name or type after it has been marked as searchable, please contact Salv Support, we can temporarily enable editing if needed.
