Outcome of a Triggered Rule

The adjustment of the customer risk level shall inevitably alter the risk to desired / chosen risk level set by the MLRO user - in this example figure shown to the left, setting the customer to a risk level of High.

As KYCMATIC has its own 'Label Management' module, as part of a rule outcome, the MLRO user may automatically set labels to the customer - Note that the labels which may be associated are solely the labels that had been created manually. Out of the box system labels may not be used since such labels are used in conjunction with other internal logical processes as part of the building of the customer profile.

KYCMATIC has an inbuilt 'Incidents & Alerts' module which shall purely provide a list of incidents & alerts to the compliance team, eliminating false positives and false negatives since all incidents & alerts being listed here have only been provided to the compliance team due to a rule the MLRO user had specifically created and therefore specifically be notified. More on this in the 'Incidents & Alerts' section of this user manual. 

KYCMATIC has inbuilt a technology known as 'Web Hook Technology' which implies that the KYCMATIC solution has the ability to communicate with other internal systems, such as a subject persons back office. 

For example, taking the €2K MGA license player deposit threshold, if a rule is invoked on a Friday evening at 21:00hrs whereby a customer / player has deposited more than €2K (or has simply exceeded the €2K threshold), a rule would be instantly invoked once the deposit transaction has come into KYCMATIC. One of the outcomes here would typically be to send (what is known as a) web hook action to a 3rd party system - typically being the back office system - which knows to send a specific set of instructions to their Payment Service Provider to stop withdrawals and deposits as well as to send a specific set of instructions to the Game Provider to Block game play for the specific user - when (for example) 'ABC_123' code is received from KYCMATIC.

Such a feature increases compliance quality as well as drastically increasing efficiencies whereby internal solutions are speaking to each other without any human interaction, effecting processes that can mean the world of a difference, for both the compliance team and for the Subject Person

The MLRO user may wish to alert a certain set of other users by sending them a notification, or an email, or both. 

Furthermore, KYCMATIC enables the MLRO user to use 'tags' whereby [RuleName] or [CustomerName] would be replaced by the actual rule name and customer name respectively, as well as being able to construct the subject and body of the notification and / or email as shown in the figure to the left. 

As mentioned in other areas of this user manual, KYCMATIC has a task management module per customer profile. Tasks are either automatically or manually generated. In this case, the MLRO user may ask KYCMATIC to associate a task with the customer if the rule is invoked.

Since the rule created in this example is time bound (over the past 7 days), this feature will not be able to be used. Yet, if the rule created is open ended and therefore not time bound, the MLRO user may opt to execute the rule retrospectively (on past data also) or from the time of creation forth. 

The MLRO user may specify when the rule is to be triggered. Leaving the time values as '00' would imply to constantly execute this rule when the specific trigger events occur. Otherwise, if a time is set, then the rule would be only executed during that set time period daily.