epic: event flow control

[Sandy-at-Tazama]

User Story

As a fraud analyst, I want to block a customer from transacting from any account So that customers that have been identified as non-compliant will not be able to transact and expose my organization to compliance risks

There are two types of conditions that can control event flow in the Tazama system:

1. Blocking conditions
   • non-overridable-block conditions (red)
   • overridable-block conditions (amber)
2. Override conditions (green)

Conditions are managed at two levels

1. Entities
2. Accounts

There are two condition perspectives

1. Debtor
2. Creditor

Hierarchy of conditions

1. Prevailing non-overridable-block conditions (red) are always applied to transactions
2. Prevailing override conditions (green) trump overridable-blocking conditions (amber)
3. If an overridable condition (amber) is not over-ridden (i.e. it is a prevailing overridable condition) it will still be applied to transactions
4. Override conditions (green) can also override a typology interdiction result and suppress an interdiction alert on a transaction event (if the EFRuP and/or interdiction workflows are configured in the Typology configuration)

Conditions (red, amber, green) would only be for one type at a time, and then for up to both perspectives, and then for an expanding number of different event types. So the branching goes from 1:2:n (condition):(perspectives):(event types)

Sequence diagram (end-to-end)

sequenceDiagram
  participant dsfp as Client System
  participant tms as TMS API
  participant ed as Event Director
  participant efrup as Event Flow<BR> Rule Processor
  participant tp as Typology Processor
  participant relay_interdict as Relay Service<BR> (interdiction)
  participant tadproc as TADProc 
  participant relay_alert as Relay Service <BR> (alert)

  dsfp->>tms: evaluateTransaction()
  tms->>ed: routeTransaction()
  tms->>dsfp: 200 Ok
  ed->>efrup: evaluateTransaction()
  alt Block
      efrup->>relay_interdict: sendInterdiction()
  end
  efrup->>tp: sendResult(block, override, none)
  tp->>tp: aggregateRuleResults
  tp->>tp: scoreTypologyResults
    alt no thresholds configured or breached
      tp->>tp: set review = false                    
    end  
    alt Alert threshold configured and breached
      tp->>tp: set review = true                    
    end
    alt Interdiction threshold configured and breached
      alt EFRuP configured and status block
        tp->>tp: set review = true                    
      end
      alt EFRuP configured and status override
        tp->>tp: set review = true                    
      end
      alt EFRUP configured and status none
        tp->>tp: set review = true                    
        tp->>relay_interdict: sendInterdiction() 
      end
      alt EFRuP not configured
        tp->>tp: set review = true                    
        tp->>relay_interdict: sendInterdiction() 
      end
    end
  tp->>tadproc: sendTypologyResult()
  alt any typology status = review
      tadproc->>relay_alert: sendAlert()
  end

EFRuP logic

[johanfol]

Can a green condition be: override = true outcome = false? And if it is, should it override a typologyResult of true to be false since green = false? Or does the overrides only happen in all cases if an outcome is true? With other words, this implementation proposes to only function as a block-list, and not as an allow-list?

Business case being: I'm investigating person A as suspected terrorist, and want to allow normal money flows as proof for an investigation, in which case I want to setup a green override on person A to make sure they can ALWAYS transact?

[johanfol]

Is this understanding correct for the state of review based on the EFRP outcomes?

stateDiagram-v2
    [*] --> review=false
    review=false --> review=true:EFRP=red/true
    review=true --> [*]
    review=false --> review=true:EFRP=amber/true \nEFRP=green/true
    review=false --> review=true:EFRP=amber/false\nEFRP=green/true
    review=false --> review=FALSE:EFRP=amber/true \nEFRP=green/false
    review=false --> review=FALSE:EFRP=amber/false\nEFRP=green/false
    review=FALSE --> [*]

[Sandy-at-Tazama]

Let me add the user stories over the weekend as they may help clarify. I'm not sure I understand the diagram above. There is only one review property, which will true, if EFRuP resulted in a different outcome to normal processing (without EFRuP) i.e. initiate an investigation if there was a block or override. Allow lists are enabled through Override which will override an overridable block condition (amber) but not a non-overridable block condition (red).

The Event flow Rule processor (EFRuP) must send a single result to the typology processor. The subRuleRef must be one of block, override or none. https://github.com/frmscoe/event-flow/issues/7