From incoming transactional data, Unit21 can flag fraudulent transactions and abnormal entities.

Flagging transactions is done using Models (also called Rules). Models are simply logical rules such as:

• Flag transactions for any entity over 500BTC
• Flag when Sarah Smith makes over 5000 transactions per month
• Flag a bank that has transactions coming from a blacklisted user

When a transaction or entity is flagged, Unit21 will alert you.

Let's create a model to flag any transactions above $10,000.00.

Create a Model with the SMB

---

Now, let's create a Model using the Scenario Model Builder to flag transactions over $10K.

The Scenario Model Builder allows users to pick from available AML/fraud scenarios and complete the logic to create a model.

1. Navigate to the Detection Models:

2. Select Create Scenario Model:

3. Select the Simple Count scenario. The Scenario Builder is a logical sentence that, when completed, finds fraudulent transactions. You need to complete the sentence logic by selecting from drop-down menu items and filling in the numbers.

4. Complete the logic of the Simple Count scenario to flag entities that transact over $10K: All entities where the count of transaction related unique transactions in a 1 day period is greater than 1.:

5. Use the filter feature (funnel icon) to flag only transactions over $10K sand Save:

6. click Next when you are done:

7. Name and define the model appropriately. You also have the option to add the model to an alert queue and tag it automatically. Click Next:

8. A model must be validated to ensure the logic is correct before it is deployed live; otherwise it will not catch fraudulent transactions.

To make sure the model logic is sound, a validation sequence will test your scenario against any data that is already in the Unit21 system. Luckily, we added transactions for Mr Baker in the previous section to fill the system with dummy data so that we can validate our scenario.

📘

A model must be validated before going live!

Your model must be validated once before it can be deployed live.

It is imperative to choose the correct validation window to test your logic against. This is done by selecting the Time Range for your scenario validation.

You can select the start time and end time during which the Unit21 system will validate your model logic. Unit21 will then gather all the transactional data in the system between the Start Time and End Time and test your logic against each transaction in the selected time frame.

You can also select the execution frequency. This is simply the number of times the model will run between the Start time and End time.

The Execution Window was selected as part of the scenario logic in the previous steps. This sectionalizes the transactional data in the validation time frame (Start time to End time).

In the Baker case, choose the following:

• start time = at least 1 day BEFORE the baker_transaction* epoch
• end time = at least 1 day AFTER the baker_transaction* epoch
• execution frequency = 12 hours
• execution window = 1 day

This means our logic will "look for transactions over $10K" and will be validated over a 3 day time frame, every 12 hours, against the transactional data from the previous day (24 hours)".

📘

In our example, we selected a month long window which created 61 windows. The baker transactions occurred on March 7 and 8th.

When you are done, select Validate at the bottom of your screen:

9. Unit21 will validate the model in the background. You can stay on this page and wait for it to finish or leave this page.

10. The page will refresh with the results when the validation is done.

11. You must download the results in the Rule Validation Files Exports window. An xls file will be downloaded with the transactions flagged during the validation period:

In our case, the rule flagged the baker transactions as expected.

At this point in time, we could:

1. Delete the model - permanently delete the model and its data
2. Duplicate the model - duplicate the model which allows an agent to change its logic
3. Activate the model - run the model live so it can start generating alerts on real transactional data

Next we will look at another way to create models (rules).