Skip to content

Commit 5318110

Browse files
Sandy-at-TazamaSandy-at-Tazama
committed
docs: refresh product docs for EFRuP
1 parent fc912e8 commit 5318110

8 files changed

+95
-166
lines changed

‎Product/configuration-management.md

+1-7
Original file line numberDiff line numberDiff line change
@@ -831,13 +831,7 @@ Given a version number **MAJOR.MINOR.PATCH (99.999.9999)**, increment the:
831831

832832
Every rule processor, typology processor and transaction aggregation and decisioning processor (TADProc) is guided by its own configuration document. The specific version of a configuration document that is required to operate a processor is defined in the network map when the evaluation routing is specified. When a processor receives an instruction from its predecessor in the evaluation flow, the processor checks the network map to determine which configuration document and version to use to perform its tasks.
833833

834-
When a new version of a configuration document is required, the updated version must be deployed to the appropriate configuration collection in the configuration database:
835-
836-
| **Collection name** | **Processor Type** |
837-
| --- | --- |
838-
| `ruleConfiguration` | [Rule processor overview - rule config](/product/rule-processor-overview-rule-config.md) |
839-
| `typologyConfiguration` | [Typologies](/product/typology-processing.md) |
840-
834+
When a new version of a configuration document is required, the updated version must be deployed to the appropriate configuration collection in the configuration database.
841835

842836
Configuration documents can be posted to the appropriate collection via the ArangoDB API, either in bulk or one-by-one. When posting a new configuration for an existing processor, the database will not allow a user to submit a configuration for an "id" and "cfg" combination that already exists in the database: a new configuration must always be assigned a unique configuration version.
843837

‎Product/event-director.md

+1-2
Original file line numberDiff line numberDiff line change
@@ -18,7 +18,6 @@
1818

1919
The foundation of the Tazama Transaction Monitoring service is its ability to evaluate incoming transactions for financial crime behaviors through the execution of a number of conditional statements (rules) that are then combined into typologies that describe the nature of the financial crime that the system is trying to detect.
2020

21-
2221
The Event Director is responsible for determining which typologies a transaction must be submitted to for the transaction to be evaluated. As part of this process, the Event Director determines which rules must receive the transaction and then which typologies are to be scored. The Event Director then routes the transaction to the individual rule processors.
2322

2423
## Event Director Context
@@ -98,7 +97,7 @@ The pruned network sub-map will accompany the transaction message to the rule pr
9897

9998
### 2.4. De-duplicate Rules
10099

101-
A single rule could be used to evaluate more than one typology. One of the primary advantages and reasons for the config-driven approach is to be able to minimize the number of times that a specific rule has to be executed. To achieve this objective, the Event Director will draft a list of all the rules in the network map and then eliminate duplicate rules from the list (the “Highlander” principle).
100+
A single rule could be used to evaluate more than one typology. One of the primary advantages and reasons for the config-driven approach is to be able to minimize the number of times that a specific rule has to be executed. To achieve this objective, the Event Director will draft a list of all the rules in the network map and then eliminate duplicate rules from the list (the 'Highlander' principle).
102101

103102
Each rule in the network map can be uniquely described by the combination of the following attributes:
104103

‎Product/event-flow-rule-processor.md

+1-3
Original file line numberDiff line numberDiff line change
@@ -15,7 +15,7 @@
1515

1616
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.
1717

18-
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:
18+
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:
1919
1. Blocking conditions
2020
- non-overridable-block conditions (red)
2121
- overridable-block conditions (amber)
@@ -206,8 +206,6 @@ sequenceDiagram
206206

207207
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.
208208

209-
If the normal typology processing results in an alert, then review will be true. If EFRuP results in a different outcome to normal typology processing, then `review` will be `true` and this will enable a fraud analyst to review the result of the evaluation.
210-
211209
**Note** The event flow rule processor result does not have a weight `wght` and will not be added to the typology score.
212210

213211
**Sample output**

‎Product/rule-processor-overview-rule-config.md

-7
This file was deleted.

‎Product/rule-processor-overview.md

+4-1
Original file line numberDiff line numberDiff line change
@@ -25,6 +25,9 @@ The Event Director is responsible for determining which typologies are applicabl
2525

2626
The rules receive the transaction, as well as the portion of the Network Map that was used to identify the rules as recipients (and by association also identifies which typologies are beneficiaries of the rule results).
2727

28+
The event flow rule processor (EFRuP) is a special rule processor that operates differently from all the other rule processors that are described on this page. Further information on EFRUP is available on the [Event Flow Processor Overview](/Product/event-flow-rule-processor.md) page.
29+
30+
2831
Each rule executes as a discrete and bespoke function in the evaluation process. It is a Tazama design principle that any given rule in the system has as small a purpose as possible and seeks to answer a single and very specific behavioral question about the transaction it is evaluation, for example:
2932

3033
- How many transactions were made by the debtor?
@@ -39,7 +42,7 @@ Our reference rule is [Rule 901 - Number of transactions performed by the debtor
3942

4043
## The rule executer
4144

42-
Individual rule processors are wrapped in a rule executer shell that handles common functions for all rule processors in a common way. While this makes rule processors easier to maintain by abstracting common code into the rule executer and leaving unique code in the rule processor, it does make the deployment process a little more complicated and onerous. In a production setting we would automate the deployment of the rule processors via Helm charts, but for our Docker Compose deployment, the process is a little more manual.
45+
Individual rule processors are wrapped in a rule executer shell that handles common functions for all rule processors in a common way. While this makes rule processors easier to maintain by abstracting common code into the rule executer and leaving unique code in the rule processor.
4346

4447
![rule-executer-design](../images/tazama-rule-executer.png)
4548

‎Product/transaction-aggregation-and-decisioning-processor.md

+59-92
Original file line numberDiff line numberDiff line change
@@ -34,57 +34,30 @@ Where interdiction is required, either option 1 and 2 above is the most suitable
3434

3535
The TADProc must retrieve the typology triggers from the Tazama configuration so that the TADProc can determine if any of the typologies results warrant an investigation.
3636

37-
The typology triggers must define a specific threshold value linked to each of the typologies that defines the following workflow outcomes:
37+
##### 7.2 The typology configuration
3838

39-
1. **Review**: If a typology score is equal to or greater than this value, the TADProc will trigger an alert to an adjacent Case Management System via egress API to initiate an investigation into the transaction.
40-
41-
2. **None**: If a typology score is less than the Review threshold, no triggered action is taken by the TADProc.
42-
43-
Additionally, if a transaction configuration for a transaction cannot be found, or is empty, no investigation will be triggered out of the transaction.
44-
45-
##### 7.2 The transaction configuration
46-
47-
The transaction configuration defines the typology alert thresholds for each of the typologies in the platform. The structure of the transaction configuration models that of the network map.
39+
The typology configuration defines the typology alert and interdiction thresholds for each of the typologies in the platform.
4840

4941
**Example**:
5042

5143
```json
52-
{
53-
"messages": [
54-
{
55-
"id": "[email protected]",
56-
"cfg": "1.0.0",
57-
"txTp": "pacs.002.001.12",
58-
{
59-
"id": "[email protected]",
60-
"cfg": "1.0.0",
61-
"typologies": [
62-
{
63-
"id": "[email protected]",
64-
"cfg": "1.0.0",
65-
"threshold": 500
66-
},
67-
{
68-
"id": "[email protected]",
69-
"cfg": "1.0.0",
70-
"threshold": 400
71-
}
72-
]
73-
}
74-
}
75-
]
76-
}
44+
"typology_name": "Rule-901-Typology-999",
45+
"id": "[email protected]",
46+
"cfg": "[email protected]",
47+
"workflow": {
48+
"alertThreshold": 200,
49+
"interdictionThreshold": 400,
50+
"flowProcessor": "[email protected]"
51+
}
7752
```
7853

7954
#### 7.3 Check typology triggers
8055

81-
If all typology results had been received, evaluate each typology against the transaction configuration to determine if an investigation is required. The outcomes of the evaluation depends on the typology score against the defined thresholds and may be to create (or update) an investigation case, or to do nothing.
82-
83-
The evaluation outcome of a typology against its thresholds must be logged for each typology, i.e. that the typology was evaluated, what the threshold was, and what the determination was (Review, or None).
56+
If all typology results had been received, the typology processor evaluate each typology against the typology configuration to determine if an investigation is required. The outcomes of the evaluation depends on the typology score against the defined alertThreshold. If the typology score is equal to or greater than the alertThreshold, the typology processor sets the typology review flag to `true`.
8457

8558
##### 7.4 Create investigation case
8659

87-
If the typology score is equal to or greater than the review threshold defined for the typology in the TADProc configuration, the TADProc will trigger a review message in JSON format to an adjacent Case Management System to flag the transaction for review.
60+
If any typology `review` flag is `true`, the TADProc will trigger a review message in JSON format to an adjacent Case Management System to flag the transaction for review.
8861

8962
The outgoing alert message contains:
9063

@@ -100,63 +73,57 @@ Sample output message:
10073

10174
```json
10275
{
103-
"transaction": { ...
104-
},
105-
"networkMap": { ...
76+
"transactionID": "d71103b09a4a47a987e4fa6d5f5497a7",
77+
"transaction": {
78+
...
79+
},
80+
"networkMap": {
81+
...
82+
},
83+
"report": {
84+
"evaluationID": "548ac93a-69e9-4acf-b804-85f7ff2c57db",
85+
"metaData": {
86+
"prcgTmDP": 12166572,
87+
"prcgTmED": 236381
10688
},
107-
"transactionResult": {
108-
"resultId": "9f896062-41d4-4a66-8ecc-b16fc6146919",
109-
"dateTime": "2021-12-09T11:13:06.000Z",
110-
"id": "[email protected]",
111-
"cfg": "1.0.0",
112-
"status": "ALRT",
113-
"description": "Alert triggered",
114-
"typologyResults": [
89+
"status": "ALRT",
90+
"timestamp": "2025-01-17T08:15:10.433Z",
91+
"tadpResult": {
92+
"id": "[email protected]",
93+
"cfg": "1.0.0",
94+
"typologyResult": [
95+
{
96+
"id": "[email protected]",
97+
"cfg": "[email protected]",
98+
"result": 200,
99+
"ruleResults": [
115100
{
116-
"id": "[email protected]",
117-
"cfg": "1.0.0",
118-
"result": 700,
119-
"threshold": 400,
120-
"ruleResults": [
121-
{
122-
"id": "[email protected]",
123-
"cfg": "1.0.0",
124-
"subRuleRef": ".01",
125-
"wght": 100,
126-
"reason": "Debtor received < 10 transactions within the last 72 hours"
127-
},
128-
{
129-
"id": "[email protected]",
130-
"cfg": "1.0.0",
131-
"subRuleRef": ".01",
132-
"wght": 100,
133-
"reason": "Creditor received >= 10 transactions within the last 24 hours"
134-
},
135-
{
136-
"id": "[email protected]",
137-
"cfg": "1.0.0",
138-
"subRuleRef": ".01",
139-
"wght": 100,
140-
"reason": "Debtor transfered an amount >= the historical maximum threshold over the last 3 months"
141-
},
142-
{
143-
"id": "[email protected]",
144-
"cfg": "1.0.0",
145-
"subRuleRef": ".01",
146-
"wght": 100,
147-
"reason": "Immediate transaction mirorring detected for debtor account"
148-
},
149-
{
150-
"id": "[email protected]",
151-
"cfg": "1.0.0",
152-
"subRuleRef": ".01",
153-
"wght": 300,
154-
"reason": "First recorded successful and complete incoming transaction received by the creditor"
155-
}
156-
]
101+
"id": "[email protected]",
102+
"cfg": "none",
103+
"subRuleRef": "none",
104+
"prcgTm": 6052681,
105+
"wght": 0
157106
},
158-
]
107+
{
108+
"id": "[email protected]",
109+
"cfg": "1.0.0",
110+
"subRuleRef": ".02",
111+
"prcgTm": 17682366,
112+
"wght": 200
113+
}
114+
],
115+
"prcgTm": 8754078,
116+
"review": true,
117+
"workflow": {
118+
"alertThreshold": 200,
119+
"interdictionThreshold": 400,
120+
"flowProcessor": "[email protected]"
121+
}
122+
}
123+
],
124+
"prcgTm": 6509701
159125
}
126+
}
160127
}
161128
```
162129

0 commit comments

Comments
 (0)