Decision rules help you turn Salv into an end-to-end rule engine - your core system sends data to Salv and Salv sends back a decision about the Transaction or Person. These decisions can be used to configure your core system to act automatically (e.g. freezing the funds, rejecting the payment, accept the person, etc.). This way the whole decision cycle is under your FinCrime Team's control and you don't have to wait behind your IT Team availability.
How does setting up decision webhooks look like
Setting up decision webhook is a tasks that involves teamwork between you, the client, and Salv.
Flow of setting up a decision webhook:
Client: decide on which actions need to be automated, e.g. freezing the account, rejecting the payment, etc.
Client: determine the alert statuses that you want to use.
Client: figure out how do you want the Decision rules to work based on your selected alert statuses. Here you need to know that the decision rules work with real-time Monitoring alerts and all Screening alerts.
Client: reach out to Salv to get help with setting it up for you.
Salv: set up decision rules in client’s environment.
Client: add PERSON or TRANSACTION trigger webhooks (depending on the type of Decision Rules).
Client: Then your IT Team will implement the automations in your system and Salv will implement the configuration for you.
NB❗️ We recommend to test the decision cycle in Salv Demo environment first and then switch to Salv Live environment. In the future, when you add an alert status or make any changes, then you need to remember to also update the decision rules accordingly. This way the automations in your core system will keep running as intended.
How do the decision rules work?
Every time an alert status is updated, it is possible to run a set of checks for all alerts related to that entity (person or transaction). The result of these checks is communicated via the webhook.
These checks are based on rules, where each rule has a command associated with it, and a list of pre-defined statuses that trigger the command.
These rules are ordered, and they strictly follow the order when they are executed. Each time a decision check is triggered, the system loads rules that are applicable, and runs them one by one until either one succeeds or there is no more left. Only the webhook for the first succeeding rule is sent.
There is 3 commands that a rule can use to check alert statuses
All Are → All statuses of alerts related to an entity should be in the list of statuses assigned to a rule
Any is → At least one status of an alert related to an entity should be in the list of statuses assigned to a rule
None are → None of the statuses of alerts related to an entity should be in the list of statuses assigned to a rule
👉 FYI: In case of persons all their historical alerts are taken into account.
Each rule also has a set of conditions, specifying if it should be checked against an entity:
Run only on final -> The rule will only be executed if all statuses of alerts related to an entity are marked as final.
Entity → Specifies if the rule should be executed for PERSON or TRANSACTION entities.
Examples
Here is the example of two decision rules that fire a webhook if all alerts for an entity have been cleared:
In-depth example - Transaction webhook
Let us assume that we have an organisation where alert statuses are configured the way as depicted in the pictures below:
Screening statuses:
Monitoring statuses:
In this organisation we have the following final decision rules for transactions:
We then process a transaction that generates three alerts, one monitoring and two screening:
Monitoring 1: NEW
Screening 1: NEW
Screening 2: NEW
The agents start their work and mark the Monitoring alert as a FALSE_POSITIVE, which triggers the rule check.
Statuses for transaction: NEW, NEW, FALSE_POSITIVE
Rule 1: fails, none are
TRUE_POSITIVE_FREEZERule 2: fails, none are
TRUE_POSITIVE_REJECTRule 3: fails, not all are
FILTEREDorFALSE_POSITIVENo webhook is sent
The 1st screening alert now gets assigned the status TRUE_POSITIVE_REJECT
Statuses for transaction: NEW, TRUE_POSITIVE_REJECT, FALSE_POSITIVE
Rule 1: fails, none are
TRUE_POSITIVE_FREEZERule 2: fails. Although there is at least one alert with status
TRUE_POSITIVE_REJECT, webhookREJECT_PAYMENTis not sent out as not all alert’s statuses are final (and the rule has a conditionAll alerts should be in final state).Rule 3: fails, not all are
FILTEREDorFALSE_POSITIVENo webhook is sent
Lastly, the agent starts working on the 2nd screening alert and assigns it the status TRUE_POSITIVE_FREEZE
Statuses for transaction: FALSE_POSITIVE, TRUE_POSITIVE_REJECT, TRUE_POSITIVE_FREEZE
Rule 1: succeeds, at least one is
TRUE_POSITIVE_FREEZESince all statuses that the transaction has are final (the rule has a condition
All alerts should be in final state=Yes), webhookFREEZE_ASSETSis sent out with the related transaction id
No further processing occurs
In-depth example - Person webhook
Let us assume that we have an organisation where alert statuses are configured the way as depicted in the pictures below:
Screening statuses:
Monitoring statuses:
In this organisation we have the following final decision rules for persons:
We then process a transaction that generates one monitoring alert, and we also perform daily screening and the same person who made the transaction got one person screening alert.
Monitoring 1: NEW
Screening 1: NEW
The agents start their work and mark the Monitoring alert as a FALSE_POSITIVE, which triggers the rule check.
Statuses related to the person: NEW, FALSE_POSITIVE
Rule 1: fails, none are
TRUE_POSITIVE_FREEZERule 2: fails, not all are
FILTEREDorFALSE_POSITIVENo webhook is sent
The agent then starts working on the daily person screening alert and comes to a conclusion that it is a true positive sanction hit and assigns the alert status TRUE_POSITIVE_FREEZE.
Statuses related to the person: TRUE_POSITIVE_FREEZE, FALSE_POSITIVE
Rule 1: succeeds, at least one alert related to the person has status
TRUE_POSITIVE_FREEZESince all statuses related to the person are final (the rule has a condition
All alerts should be in final state=Yes), webhookFREEZE_ACCOUNTis sent out with the related person id.
No further processing occurs
Webhook
If the rules succeeds, the webhook is sent out with TRANSACTION or PERSON trigger, that has the rule name as action and a transaction/person id as a payload.
{
"action": "FREEZE_ASSETS",
"createdTime": "2019-08-24T14:15:22Z",
"metadata": {
"transactionId": "transaction-000000X"
}
}{
"action": "FREEZE_ACCOUNT",
"createdTime": "2019-08-24T14:15:22Z",
"metadata": {
"personId": "user-000000X"
}
}