Eclipse supports a comprehensive transaction monitoring and fraud prevention platform to automatically classify and detect fraudulent activities in real-time. Additionally, the system is highly customizable, offering the flexibility to create and implement custom fraud detection rules tailored to your specific needs.

Eclipse can plug into third party engines and for certain known ecosystems, where fraud data can be used for training, we have implemented sophisticed machine learning fraud engines.

The transaction monitoring engine comprises the following cababilities:

1. A flexible fraud event data model that allows the definition of fraud events based on loosely typed data
2. The ability for Eclipse to automatically publish fraud events across the range of Eclipse transaction types
3. The ability for third parties to publish fraud events
4. A sophisticated machine learning engine to assess and score fraud events in realtime - including aggregation logic
5. The ability for Eclipse to define custom fraud rules to run against fraud events - including aggregation logic
6. The ability for Eclipse to integrate via several handlers to publish fraud events to third party transaction monitoring tools

Creating Custom Fraud Rules

To define custom fraud rules requires custom configuration - please contact your account manager for more details. The following information is required to define a new custom fraud rule:

1. Name and Description

Plain english simple description of the rule - can be used to map back to externally defined business rules.

Example

Name: Dormant Wallet Limit
Description: Rule to detect transactions over a certain threshold on wallets where there have been no transactions for more than 60 days.

2. Filter Criteria

This determines what users the particular fraud rule should be applied to. This can be applied across all tenants, groups of tenants (e.g. for a specific region) or specific tenants. Fraud rules can also filter by event type - event types published for Eclipse transactions include:

• PRE-PAYMENT
• POST-PAYMENT
• PRE-WITHDRAWAL
• POST-WITHDRAWAL
• WALLET-CREDIT
• WALLET-DEBIT

Exceptions can also apply e.g. exclude a certain tenant or group of tenants.

Example

The fraud rule should apply to all tenants in the South Africa region, except for tenants X, Y and Z and should be run on all transactions on a wallet (WALLET-DEBIT and WALLET-CREDIT)

3. Fraud Rule Query

This defines the query to apply to the event to determine if the fraud rule has been fired. These are typically configured as SQL queries that can take any fields in the fraud event as input parameters and can run against historical data if the rule is an aggregate or sum.

Example

This event should be considered fraud if it is a transaction of a wallet that has not had any transactions on it for more than 60 days

4. Action

This defines the action that must be carried out if the event is considered fraud. The following are supported actions:

• BARRED_WALLET: The transaction must be denied and the wallet must be barred
• BARRED_CUSTOMER: The transaction must be denied and the customer must be barred
• DONT_ALLOW: The transaction must be denied.
• USE_HIGHEST: Funds must ne locked for a specified period of time

In addition notification actions can be configured - e.g. send an email or raise a Jira ticket.

Example

If this fraud rule is fired the transaction should be allowed to proceed but a Jira ticket should be logged to the compliance team for further investigation.