docs: update to EFRuP docs

Author: Sandy-at-Tazama

Product/event-flow-rule-processor.md

@@ -15,7 +15,7 @@
 
 The event flow rule processor (EFRuP) is a special rule processor that operates alongside all the other rule processors and enables operational control over the normal Tazama system functioning, for example, to be able to block a customer from transacting from any account or to override an interdiction and allow a transaction where it would otherwise have been blocked.
 
-The EFRuP can be configured to block or allow a transaction based on the evaluation of conditions against one of the transaction attributes. There are two types of conditions that can control event flow in the Tazama system, that can be created on a debtor or creditor: 
+The EFRuP can be configured to block or allow a transaction based on the evaluation of conditions against one of the transaction attributes. There are two types of conditions that can control event flow in the Tazama system. These conditions can be created on a debtor or creditor: 
 1.	Blocking conditions
     - non-overridable-block conditions (red)
     - overridable-block conditions (amber)
@@ -207,6 +207,10 @@ sequenceDiagram
 If a typology score is equal to or greater than the threshold value and there is an override in place, the Typology Processor will not trigger an interdiction workflow to instruct the client system to block the transaction event.
 
 **Note** The event flow rule processor result does not have a weight `wght` and will not be added to the typology score. 
+
+If the event flow processor is applicable to a typology, the EFRuP rule must be added to the list of rules in the typology configuration and EFRuP `"flowProcessor": "[email protected]"` will be added to the workflow object.
+
+`flowProcessor` may be omitted from the workflow object and the rules list in which case a particular typology is not affected by EFRuP results.
 
 **Sample output**
 

Product/typology-processing.md

@@ -164,7 +164,7 @@ Once the calculation of the typology score is complete, the Typology Processor m
 
 ### 5.8 A note on typology interdiction
 
-It makes sense for the typology processor to be able to interdict a transaction directly, if the threshold for interdiction has been met,s unless there is an override in place, in which case the Typology Processor will not trigger an interdiction.
+The typology processor will interdict a transaction directly if the threshold for interdiction has been met, unless there is an override in place in which case the typology processor will not trigger an interdiction.
 
 1. For a given typology, a specific threshold value must be linked to the typology for the following workflow outcomes:
     1. **Interdiction**: If a typology score is equal to or greater than this value, the Typology Processor will trigger an interdiction workflow to instruct the client system to block the transaction, unless there is an override in place, in which case the Typology Processor will not trigger an interdiction.

README.md

@@ -43,7 +43,7 @@ By assessing the transfer to the fraudsters, it is possible to identify more hig
 
 If the Fraudster recipient was the customer being monitored it is likely they will receive the funds, and quickly move it to the next person in their money laundering chain. This would be captured in a Layering Typology which would include age of the account or dormant account suddenly becoming active instead of age of the participant.
 
-In the creation of a typology, it is worth highlighting that our phishing example can also create a false positive when a grandparent sends a large sum for an important life event to one of their grandchildren. Previously gifts had been sent via the parents and as such no historical financial relationship had been established. It is for this reason that a rule such as 'allow-list of sender and receiver pairs' can be implemented. The typology will then assess if this transaction can be progressed because it is approved in the override request. It is worth noting that a diligent fraudster would look to circumnavigate this control by sending a small transaction that would be allowed, and then moving larger amounts once the history had been established. It is therefore important that an understanding of the customers in a given FSP is developed, as finding the balance of low false positives and managing the activity of fraudsters 'testing the boundaries' are critical to the success of an implementation.
+In the creation of a typology, it is worth highlighting that our phishing example can also create a false positive when a grandparent sends a large sum for an important life event to one of their grandchildren. Previously gifts had been sent via the parents and as such no historical financial relationship had been established. It is important that an understanding of the customers in a given FSP is developed, as finding the balance of low false positives and managing the activity of fraudsters 'testing the boundaries' are critical to the success of an implementation.
 
 <div style="text-align: right"><a href="#top">Top</a></div>
 
@@ -92,7 +92,7 @@ A rule can be used to assess more than one outcome, such as age bands if needed,
 
 Rule processors are templated so that logging, data input, determined outcomes, data output and telemetry are consistently applied by all rule processors. It is just the specific rule's logic, including the queries that retrieve transaction history according to the rule requirements, that changes between rules. Rules must be developed individually, but the parameters used in the calculation of a rule and its outcomes are contained in a configuration file. The rule behavior can be configured independent of the rule code, reducing the operational burden for modifying a rule to a mere configuration process.
 
-The event flow rule processor (EFRuP) is a specialised rule processor that enables the system to exert operational control over evaluations based on the outcome of business processes and prior evaluations. The system is able to block or override a transaction event based on the evaluation of conditions against one of the transaction event attributes. Further information on EFRUP is available on the [Event Flow Processor Overview](/Product/event-flow-rule-processor.md) page.
+The event flow rule processor (EFRuP) is a specialised rule processor that enables the system to exert operational control over evaluations based on the outcome of business processes and prior evaluations. The system is able to block or override a transaction event based on the evaluation of conditions against one of the transaction event attributes. Further information on EFRuP is available on the [Event Flow Rule Processor Overview](/Product/event-flow-rule-processor.md) page.
 
 Once the rule processor has completed its evaluation, the output is forwarded to the Typology Processor.
 
@@ -118,7 +118,7 @@ If a suspicious transaction is identified, there are a number of actions that ca
  - **Moderate** - an investigation alert to a case management systems can be created once the evaluation of all the typologies are complete;
  - **Low** - the transaction will pass without intervention, but the evaluation outcome will be stored for future retrieval.
 
-The typology score is evaluated against an 'interdiction' threshold to determine if the client system should be instructed to block a transaction 'in flight'. The Event Flow processor can be configured to override the interdiction outcome for a typology for a specific account or entity. 
+The typology score is evaluated against an 'interdiction' threshold to determine if the client system should be instructed to block a transaction 'in flight'. The Event Flow rule processor can be configured to override the interdiction outcome for a typology for a specific account or entity. 
 
 Further information on the role of the Typology Processor is available on the [Typology Processing](/Product/typology-processing.md) page.