Compliance Rule Algorithms

This page is accessed via Master Data > Power Data > Compliance Rules > Compliance Rule Algorithms.

Use this page to view the algorithms available to you. You cannot make any alterations, i.e. this page is view-only.

The Compliance Rule Screening Service supports transactional screening of personal information, product and usage information, location information, and user defined conditions. GTM supports Export Administration Regulations (EAR) and cumulative algorithms. Based on the algorithm, the service uses the corresponding algorithm handler for screening purposes. The handler takes in rule set group ID or rule set ID, and calls the rule engine to match the conditions of corresponding rules and transactional conditions. After getting the matched rule IDs from the rules engine, the handler query rule controls and processes these controls based on screening logic which is defined in this handler.

Basically, each regulation should have its own handler. For example, the EAR control handler is for EAR algorithm and Cumulative control handler is for cumulative algorithm.

• Compliance Rule: A rule contains category, conditions, and controls. The control category (License, License Exception,or Sanction) is required. The override license type and override license code are required for license exception rules.
• Compliance Rule Set: A compliance rule set is nothing but a set of rules. The rules engine screens rules based on a rule set.
• Compliance Rule Group: A rule group can have multiple rule sets. Users set up compliance algorithm and screening parameters. There are three parameters (Control Override, Exception Override, and Exception Restriction) which are used by the EAR control handler.
• EAR algorithm: The algorithm is designed for EAR regulation.
• • Based on EAR regulation, there is at most one control and one control exception for each rule set. If you identify multiple controls in a rule set, the control with highest precedence will be applied. The EAR algorithm is only applicable when specifying a control category of License, License Exception, or Sanction on the compliance rule. For all other available control categories, the cumulative algorithm will be used.
  • Three flags (Control Override, Exception Override, and Exception Restriction) determine how controls and control exceptions among rule sets are evaluated. The screening logic is as follows. Eventually, there is at most one control and one control exception for entire rule group based on the following screening logic:

Current License	Current Exception	Control Override	Exception Override Type	Move to Next Rule Set	Search Control	Search Exception
N	N	If license is found in current round, then overall exception is null and you search for new exception.	If license is not found in current round, then you do not search for exceptions in current round.	Y	Y	Y
Y	N	N	N	N
		N	Y	N
		Y	N	Y	Y	Y
		Y	Y	Y	Y	Y
Y	Y	N	N	N
		N	Y	Y	Y	Y
		Y	N	Y	Y	Y
		Y	Y	Y	Y	Y
Special case of handling a restriction on a license (will require a new flag in the rule_group_set_join table - is_exception_restriction)
N	N	Flag on rule set that indicates that this is a restriction on use of exception.	Do nothing.
Y	N	Flag on rule set that indicates that this is a restriction on use of exception.	Do nothing.
Y	Y	Flag on rule set that indicates that this is a restriction on use of exception.	If you match a license rule then you have a restriction to the exception. You then match to exception rules. If you match this means that you can use the original exception. If not then you need the original license and you cannot use an exception.

 

• Cumulative algorithm: The cumulative handler returns whatever it matches. For example, Unlike EAR handler, the cumulative handler ignores control precedence and returns all matched controls and control exceptions for each rule set. The screening flags do not apply to cumulative algorithm.

Note: If you are logged in as DBA.ADMIN you can make changes to the algorithm description only.