These tables provide a closer look at the tables and fields that are accessible for Monitoring Scenarios and Risk Rules in Salv Platform. Below is an ER (Entity Relation) diagram of the schema available to scenarios and risk rules.

Table Descriptions:

Transaction

Most rules start with the TRANSACTION table, which contains all of the transaction data that you have sent to Salv. Here is an overview of the usable fields:

Field Name	Type	Description
id	integer	Salv internal ID for the transaction, usually referenced in real-time and post-event scenarios as the triggering transaction in the where clause of the scenario, e.g. `from transaction new where new.id = $transactionId`
external_id	text	Your organisation’s ID for the transaction
person_id	integer	The person ID for the transaction and foreign key to PERSON table. Useful for joining other transactions from this person, e.g. `join transaction past on past.person_id = $personId`
created_time	timestamp with time zone	Timestamp of when the transaction was created in Salv system
customer_id	integer	Your organisation ID is in this column. Useful when joining or searching for transactions from your organisation that are not from the same person as the triggering transaction, e.g. `where not exists ( select 1 from transaction where attributes->’ip_address’ = new.attributes-> ’ip_address’ and customer_id = $organisationId and person_id != $personId )`
type	text	The transaction type, e.g. wire_transfer, internal, international_transfer, etc
status	text	Transaction status, e.g. completed, settled, failed, pending, etc
timestamp	timestamp with time zone	Timestamp of the transaction which you sent to Salv. Note: in case transaction past table is filtered by `timestamp`, `$transactionTimestamp` must be used. This variable contains the value of triggering (currently processed) transaction `timestamp`.
amount	numeric	Amount of the transaction. Can be original amount or converted into some other currency, e.g. EUR, however Salv does not do currency conversion
reference	text	The payment reference sent along with the transaction, which is typically screened and monitored for red flag words, e.g. `select true, reference from transaction where new.id = $transactionID and reference ~* $red_flag_words`
sender_name	text	Name of the sender of the transaction
sender_account	text	Account number, e.g. IBAN, of transaction sender
receiver_name	text	Name of the receiver of the transaction
receiver_account	text	Account number, e.g. IBAN, of transaction receiver
direction	text	Direction of the transaction: ‘INCOMING’ or ‘OUTGOING’
updated_time	timestamp with time zone	Timestamp of when transaction was last updated, e.g. with a change of status field
attributes	hstore	This hstore column includes all other attributes that you send to Salv with the transaction, e.g. sender_country, ip_address, etc. They can be referenced in scenarios and risk rules as well, e.g. `where new.attributes->'sender_country' not in ($prohibitied_countries)`

Person

The most common table you will join in a transaction monitoring scenario is the PERSON table, which contains all of the person data that you have sent to Salv. Here is an overview of the usable fields:

Field Name	Type	Description
id	integer	Salv internal ID for the person in Salv system and should be used to join the PERSON table, e.g. `join person p on p.id = $personId and p.customer_id = $organisationId` , or in risk rules and person monitoring scenarios, e.g. `from person p where p.id = $personId and p.customer_id = $organisationId`
external_id	text	Your organisation’s ID for the person
created_time	timestamp with time zone	Timestamp of when the person was created in Salv system
customer_id	integer	Your organisation ID is in this column. Useful to include for performance reasons when joining person data, e.g. `from person p where p.id = $personId and p.customer_id = $organisationId`
type	varchar(255)	Type of the person, e.g. ‘INDIVIDUAL’, ‘BUSINESS’, ‘PRIVATE’, ‘LEGAL’, etc.
first_name	text	First name of the person if a private entity, e.g. Ragnar
last_name	text	Last name of the person if a private entity, e.g. Ragnarsson
company_name	text	Name of the company if a legal entity, e.g. Salv
dob	date	Date of birth of the person if a private entity in DD/MM/YYYY format
email	text	Email address of the person
phone_number	text	Phone number of the person
street_address	text	Street address information
city	text	City information, e.g. London
country	text	Country information, best to include in standardised format, e.g. ISO-2 digit format, ‘UK’
category	text	For counterparty monitoring, indicates if this person is a counterpary with value ‘COUNTERPARTY’
attributes	jsonb	This jsonb column includes all other attributes that you send to Salv with the person data, e.g. shareholders and UBOs (nested data containing personal information on company shareholders and UBOs), industry, risk_level, max_turnover_per_month. These attributes can be referenced in scenarios and risk rules as well, e.g. `select new.amount > (p.attributes->>'max_incoming_amount')::numeric, new.amount, p.attributes->>'max_incoming_amount' from transaction new join person p on p.id = $personId and p.customer_id = $organisationId where new.id = $transactionId`

Person Aggregate (person_aggregate)

The PERSON AGGREGATE table contains data from aggregations that have been set up for your organisation related to persons. These aggregations are synchronously calculated with new transactions, so the data is available to use immediately for real-time scenarios (but this table can be used in post-event and periodic scenarios as well). Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table, same as person_id in TRANSACTION table, useful for joining PERSON AGGREGATE table, e.g. `join person_aggregate past on past.person_id = $personId and past.organisation_id = $organisationId`
organisation_id	integer	Your organisation ID is here. This should be included in the join statement and speeds up performance.
aggregate_date	timestamp	The date for which transactions are aggregated, with the timestamp at midnight (the very beginning of the day) for that date in UTC time. Note: in case `person_aggregate` table is filtered by `aggregate_date`, then filtering by `$transactionTimestamp::timestamp` must be used. This variable contains the value of triggering (currently processed) `transaction new` timestamp. The conversion to timestamp must be used because `aggregate_date` column in `person_aggregate` is without timezone.
aggregate_type	text	The name of the aggregation, e.g. TRANSACTIONS_FROM_SENDER, COMPLETED_TRANSACTIONS_TO_COUNTRY, etc.
aggregate_operation	text	Four possible values, depending on the kind of aggregation: MAX, MIN, COUNT, SUM
transaction_direction	text	INCOMING or OUTGOING (or UNDEFINED, if not specified)
transaction_type	text	The type of transaction which is aggregated, from TRANSACTION table, type field
value	numeric	This is the numeric value which is aggregated, whether it is a sum of transaction amount, count of transactions, etc and is the field to use when summing for a period, e.g. `select sum(past.value) > threshold, sum(past.value) from transaction new join person_aggregate past on past.person_id = $personId and past.organisation_id = $organisationId where new.id = $transactionId and past.aggregate_date <= new.timestamp and past.aggregate_date >= new.timestamp - '3 months'::interval and past.aggregate_type = 'TRANSACTIONS_FROM_COUNTRY' and past.direction = 'INCOMING' and past.aggregate_operation = 'COUNT' and past.attribute_value in ($high_risk_countries)`
created_time	timestamp	When the aggregation for this day was created, e.g. the first transaction that meets the aggregation conditions for that day, UTC time
updated_time	timestamp	Last time the aggregation was updated, e.g. the last transaction that meets the aggregation conditions for that day, UTC time
attribute_value	text	Optional field used to store some other field value, e.g. sender_account for TRANSACTIONS_FROM_SENDER, or the country to which the transaction was sent for TRANSACTIONS_TO_COUNTRY

Service Provider Aggregate (service_provider_aggregate)

Similarly to PERSON AGGREGATE table, the SERVICE PROVIDER AGGREGATE table contains data from aggregations set up for your organisation related to service provider customers. However, these aggregations are asynchronously calculated and should only be used in PERIODIC monitoring scenarios. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table, same as person_id in TRANSACTION table, useful for joining SERVICE PROVIDER AGGREGATE table and as first line in PERIODIC scenario queries, e.g. `join service_provider_aggregate past on past.person_id = $personId and past.organisation_id = $organisationId` , `select person_id, … from service_provider_aggregate …`
organisation_id	integer	Your organisation ID is here. This should be included in the join statement and speeds up performance.
timestamp	timestamp with time zone	The date for which transactions are aggregated, with the timestamp at midnight (the very beginning of the day) for that date
type	text	The name of the aggregation, e.g. SERVICE_PROVIDER_1_TRANSACTIONS_TO_COUNTERPARTY, SERVICE_PROVIDER_2_TRANSACTIONS_FROM_COUNTRY
operation	text	Four possible values, depending on the kind of aggregation: MAX, MIN, COUNT, SUM
direction	text	Optional for transaction direction: ‘I’ for incoming, ‘O’ for outgoing, or null
value	numeric	The numeric value which is aggregated, whether it is a sum of transaction amount, count of transactions, etc and is the field to use when summing for a period, e.g. `select person_id, sum(past.value) > threshold, sum(past.value) from service_provider_aggregate past where past.timestamp <= now() and past.timestamp >= now() - '1 month'::interval and past.type = 'SERVICE_PROVIDER_2_TRANSACTIONS_FROM_COUNTRY’ and past.operation = 'SUM' and past.direction = 'I' and past.attribute_value in ($high_risk_countries) group by person_id`
currency	text	Optional field for the type of currency if you need aggregations for different currencies to be stored separately
created_time	timestamp with time zone	When aggregation was created for this day
updated_time	timestamp with time zone	The last time the aggregation was updated for the day
attribute_value	text	Optional field used to store some other field value, e.g. receiver_account for SERVICE_PROVIDER_1_TRANSACTIONS_TO_COUNTERPARTY, or the country from which the transaction was sent for SERVICE_PROVIDER_2_TRANSACTIONS_FROM_COUNTRY
metadata	jsonb	This field contains additional metadata saved with the aggregation needed to create an alert, e.g. counterparty name for SERVICE_PROVIDER_1_TRANSACTIONS_TO_COUNTERPARTY or receiver_name for SERVICE_PROVIDER_2_TRANSACTIONS_FROM_COUNTRY

Service Provider Person (service_provider_person)

The SERVICE PROVIDER PERSON table contains data on the service providers that have aggregations within the SERVICE PROVIDER AGGREGATE table, most importantly, the ID of the service provider. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table, present also in SERVICE PROVIDER AGGREGATE table
organisation_id	integer	Your organisation ID is here and should be used to join the table, e.g. `join service_provider_person spp on spp.person_id = service_provider_aggregate.person_id and spp.organisation_id = $organisationId`
external_service_provider_id	text	Your ID for the external service provider
created_time	timestamp with time zone	Timestamp of when the service provider person was created in Salv system

Active Final Risk (active_final_risk)

The ACTIVE FINAL RISK table contains the current final risk level for each of your persons, if you use Salv’s Risk tool. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table, same as person_id in TRANSACTION table, use to join ACTIVE FINAL RISK table, e.g. `join active_final_risk afr on afr.person_id = $personId and afr.organisation_id = $organisationId`
organisation_id	integer	Your organisation ID is here. This should be included in the join statement and speeds up performance.
level	text	The current final risk level of the person from Salv’s Risk tool. Possible values: LOW, MEDIUM_TO_LOW, MEDIUM, MEDIUM_TO_HIGH, HIGH, UNACCEPTABLE
start_time	timestamp with time zone	The start time of the current final risk level. If there is a risk rescoring that does not change the final risk level, then this field is not updated.
overridden	boolean	If you use an override to the final risk level as scored by Salv’s Risk tool, this field is TRUE. If there is no override, then it is FALSE.

Custom List Value (custom_list_value)

The CUSTOM LIST VALUE table contains the usable fields and data that you have put into your custom lists. Please see this page for information on using custom lists in monitoring scenarios. Here is an overview of the usable fields:

Field Name	Type	Description
value	text	This field contains the value from the field that you have indicated is a usable field for monitoring, e.g. a name, ID, country code, etc.
list_code	text	This contains the code to be able to reference the appropriate custom list in the monitoring scenario. The format is #LIST-LIST_CODE, where LIST_CODE is the code that you have given to your list, e.g. CLIENTS_FOR_MONITORING
field_code	text	This contains the code to be able to reference the appropriate field from the desired custom list in the monitoring scenario. The format is #LIST-LIST_CODE-FIELD_NAME, where FIELD_NAME is the name of the field, e.g. ACCOUNT_NUMBER.
organisation_id	integer	Your organisation ID is here and is needed to join the CUSTOM LIST VALUE table to reference in the scenario query.
additional_data	jsonb	This field contains additional data about your custom list entry that may be useful for generating an alert or to add to the alert details, e.g. select true ,new.sender_account ,custom_list_value.additional_data->>'name' as customer_name ,custom_list_value.additional_data->>'reason' as reason from transaction new join custom_list_value on new.customer_id = custom_list_value.organisation_id where new.id = $transactionId and custom_list_value.organisation_id = $organisationId and custom_list_value.list_code = '#LIST-CLIENTS_FOR_MONITORING' and custom_list_value.field_code = '#LIST-CLIENTS_FOR_MONITORING-ACCOUNT_NUMBER' and new.sender_account = custom_list_value.value

Previous Monitoring Alerts (previous_monitoring_alerts)

The PREVIOUS MONITORING ALERTS table contains data on past monitoring alerts for persons in your data. This is useful if you would like to incorporate this information to have, for example, different thresholds depending on the number of past alerts, or change the monitoring period of a scenario based on a past alert. Please see this page for more detailed information on referencing previous monitoring alerts in scenarios. Here is an overview of the usable fields:

Field Name	Type	Description
transaction_id	integer	The transaction ID of the transaction which triggered the alert, if the scenario_entity_type is ‘TRANSACTION’ (the value is null otherwise). Foreign key to TRANSACTION table.
person_id	integer	The person ID of the person on whom the alert was triggered. Foreign key to PERSON table.
organisation_id	integer	Your organisation ID is here and should be included in the join or exists statement for accessing the PREVIOUS MONITORING ALERTS table in the scenario query.
created_time	timestamp with time zone	Timestamp of when the previous alert was created.
scenario_handle	uuid	The unique identifier of the scenario, which can be found in the URL on the scenario page.
scenario_entity_type	text	Possible values: TRANSACTION (for Transaction Monitoring scenarios) and PERSON (for Person Monitoring scenarios)
scenario_type	text	Indicates scenario type: ONLINE, OFFLINE, or PERIODIC
reason	text	The scenario reason - the name of the scenario, e.g. “Possible Transit Activity”, “High Value Transaction”
interval	integer	For PERIODIC scenarios, indicates the numeric part of the scenario monitoring interval, e.g. 1
interval_time_unit	text	For PERIODIC scenarios, indicates the unit of time of the scenario monitoring interval, e.g. MONTH
alert_details	text	This field contains the details of the alert, which comes from the “Details” box in the scenario version page
current_status	text	The code of the current status of the alert, e.g. NEW, CLOSED_AS_FALSE_POSITIVE
current_status_created_time	timestamp	The start time of the current status, i.e. when it was created/last changed
status_id	bigint	The ID of the current status, which is a foreign key to the MONITORING FINAL STATUS or MONITORING NONFINAL STATUS table, depending on if the status is final or not final

Monitoring Final Status (monitoring_final_status)

The MONITORING FINAL STATUS table contains all statuses for monitoring alerts that you have indicated are final statuses, e.g. CLOSED_AS_FALSE_POSITIVE and any custom statuses you may have which are final statuses. Please see here for more detailed information on custom alert statuses. Here is an overview of the usable fields:

Field Name	Type	Description
id	bigint	ID of the status, which can be referenced in other tables as status_id
organisation_id	integer	Your organisation ID is here and should be used in the join or exists clause when referencing the table in scenarios
code	text	The code of the status for reference in scenario queries, e.g. CLOSED_AS_FALSE_POSITIVE
name	text	The human readable name of the status, e.g. “Closed - False Positive”
is_active	boolean

Monitoring Nonfinal Status (monitoring_nonfinal_status)

The MONITORING NONFINAL STATUS table contains all statuses for monitoring alerts that you have indicated are not final statuses, e.g. PENDING, ESCALATED, etc. and any custom statuses you may have which are not final statuses. Please see here for more detailed information on custom alert statuses. Here is an overview of the usable fields:

Field Name	Type	Description
id	bigint	ID of the status, which can be referenced in other tables as status_id
organisation_id	integer	Your organisation ID is here and should be used in the join or exists clause when referencing the table in scenarios
code	text	The code of the status for reference in scenario queries, e.g. CLOSED_AS_FALSE_POSITIVE
name	text	The human readable name of the status, e.g. “Closed - False Positive”
is_active	boolean

Person Tag (person_tag)

The PERSON TAG table contains data from Salv’s Screening Product if a person has had a true positive screening alert and has been tagged with one of the labels: PEP, SANCTION, ADVERSE_MEDIA, ADVERSE_MEDIA_ENTITY, or CUSTOM_SCREENING_LIST. This information can be used to inform Risk Rules or within Monitoring Scenarios. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table
organisation_id	integer	Your organisation ID is here and should be used in the join or exists clause when referencing the table in scenarios or risk rules
tag	text	Possible values: PEP, SANCTION, ADVERSE_MEDIA, ADVERSE_MEDIA_ENTITY, or CUSTOM_SCREENING_LIST
created_time	timestamp	When the person tag was created
updated_time	timestamp	The last time when the person tag was updated (the most recent true positive alert that resulted in the tag)

Person Attributes History (person_attributes_history)

The PERSON ATTRIBUTES HISTORY table provides the history of the person data that you have sent to Salv, with essentially the same fields as the PERSON table. There are multiple rows for each person ID which show the history of their attributes. It is useful in a Person Monitoring or Risk Rule context, for example, to look at location, login, device, or IP address history or the history of any other person attribute. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table
organisation_id	integer	Your organisation ID is here and should be used for joining the table to improve performance, e.g. `join person_attributes_history pah on pah.person_id = $personId and pah.organisation_id = $organisationId`
created_time	timestamp	Timestamp of when these attributes were created in Salv system, UTC time
start_time	timestamp	Timestamp of when these attributes were current in PERSON table, UTC time, virtually always identical to created_time
end_time	timestamp	Timestamp of when these attributes were overwritten by the next update to PERSON table, null value if these are the current attributes, UTC time
first_name	text	First name of the person if a private entity, e.g. Ragnar
last_name	text	Last name of the person if a private entity, e.g. Ragnarsson
company_name	text	Name of the company if a legal entity, e.g. Salv
dob	date	Date of birth of the person if a private entity in DD/MM/YYYY format
email	text	Email address of the person
phone_number	text	Phone number of the person
street_address	text	Street address information
city	text	City information, e.g. London
country	text	Country information, best to include in standardised format, e.g. ISO-2 digit format, ‘UK’
attributes	jsonb	This jsonb column includes all other attributes that you send to Salv with the person data, e.g. shareholders and UBOs (nested data containing personal information on company shareholders and UBOs), industry, risk_level, max_turnover_per_month, etc. These attributes can be referenced in scenarios and risk rules as well, e.g. `person_attributes_history ->> 'device_id'`

Person Monitoring Alert Count (person_monitoring_alert_count)

The PERSON MONITORING ALERT COUNT table provides the number of alerts on each person ID, separated by the current status of those alerts, and is useful in a Scenario or Risk Rule context to factor in the count of previous monitoring alerts. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table
organisation_id	integer	Your organisation ID is here and should be used to join the table for better performance, e.g. `join person_monitoring_alert_count pmac on pmac.person_id = $personId and pmac.organisation_id = $organisationId`
alert_count	numeric	Contains the count of monitoring alerts for the specific person_id and status values
status	text	Contains the current status code of the alerts, e.g. CLOSED_AS_TRUE_POSITIVE, NEW, PENDING, etc.

Person Status (person_status)

The PERSON STATUS table provides the current status of the person as selected in the top-right corner of the customer page on app.salv.com/customer/{{person external_id here}}. The possible values that person status can take are: NEW, REVIEWED, MONITORING, SUSPENDED, TERMINATED, and TERMINATED_AND_REPORTED. The table and status value is useful in Screening exemption rules, but also in a Monitoring and Risk Rule context to only consider persons of a specific status. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table
organisation_id	integer	Your organisation ID is here and should be used to join the table for better performance, e.g. `join person_status ps on ps.person_id = $personId and ps.organisation_id = $organisationId and ps.end_time is null`
assigner_id	integer	The ID of the user of Salv application who assigned the person status
status	text	Status value. Possible values: NEW, REVIEWED, MONITORING, SUSPENDED, TERMINATED, and TERMINATED_AND_REPORTED
created_time	timestamp	Timestamp of when the status was created in Salv system, UTC time
start_time	timestamp	Start time of the specified status, UTC time
end_time	timestamp	End time of the specified status, UTC time, when it was overwritten by the next status change. Null value if it is the current status value.

Transaction Person Relation (transaction_person_relation)

The Transaction Person Relation table provides relation between detected counterparty and transaction. One transaction can be related upto 3 persons. 1 regular person and 2 counterparties. This table is used in counterparty monitoring. Here is an overview of the usable fields:

Field Name	Type	Description
person_id	integer	Foreign key to PERSON table
organisation_id	integer	Your organisation ID is here
transaction_id	integer	Foreign key to TRANSACTION table