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:

A flexible fraud event data model that allows the definition of fraud events based on loosely typed data
The ability for Eclipse to automatically publish fraud events across the range of Eclipse transaction types
The ability for third parties to publish fraud events
A sophisticated machine learning engine to assess and score fraud events in realtime - including aggregation logic
The ability for Eclipse to define custom fraud rules to run against fraud events - including aggregation logic
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.

Mapping Fraud Events to Third-Party Engines

Eclipse provides support for integrating third-party fraud detection systems by allowing them to publish fraud events through the Fraud Event API.

Fraud event object

Each fraud event includes:

messageType: Identifies the type of event or transaction

handlerType: Determines which custom handler to invoke

Custom/dynamic fields relevant to the specific integration

A custom handler must be defined for each third-party system. Eclipse uses the handlerType from the event to route to the appropriate handler implementation.

Field mapping configuration

To support flexible data formats, Eclipse enables incoming and outgoing message mapping configurations per message type and handler. These mappings allow transformations across formats such as:

JSON ↔ JSON
JSON ↔ XML
XML ↔ XML
XML ↔ JSON

Custom formats (e.g, TCP Socket connections) can also be supported.

Field mapping configurations use JsonPath or XPath-like mappings for field extraction
Allow nested mappings using dot notation (e.g., parent.child.key)
Custom XML root tags are supported
Provides complete flexibility for field-level transformation without code changes - just configuration.

Postilion-Specific Integration

A common integration pattern for Postilion systems involves an external processing node that sends requests to Eclipse via PostBridge. In this flow, a PostBridge handler converts ISO messages into fraud events and populates the appropriate handlerType and messageType fields for further processing by Eclipse.

Example

The following example indicates the configuration and API calls for a 3rd party system to publish fraud events with JSON and to have field mappings configured to map the JSON to XML to call a SAS fraud engine.

Prerequisites:

Global property property fraud.event.handlers set to define the fraud handler type e.g.:

SAS=com.ukheshe.services.fraud.publish.sas.SASFraudPublishHandler

Global property fraud.event.handler.{handler_type}.field-mappings.outgoing.{message_type} set to define the field mappings from incoming fraud events to the messages to the particular handler:

txCode=$.transactionType
amount=$.transactionAmount

Global property fraud.event.handler.{handler_type}.field-mappings.incoming.{message_type} set to define the field mappings from responses from a particular handler:

outcome=$.fraudOutcome
message=$.message

Publish fraud event:

The message field contains the dynamic set of fields to be mapped to the handler.

POST /eclipse-conductor/rest/v1/tenants/{tenantId}/fraud-event
{
  "handlerType": "SAS",
  "message": "{\"transactionType\":\"purchase\",\"transactionAmount\":100}",
  "messageFormat": "JSON",
  "messageType": "purchase"
}

Example SAS request and response

Based on the example configuration in fraud.event.handler.sas.field-mappings.request.purchase:

{
  "txCode": "purchase",
  "amount": 100
}

Example SAS response body (not a real response, just for illustrative purposes)

{
  "fraudOutcome": "F",
  "message": "Fraud detected"
}

Example Eclipse response to fraud API

Based on the example configuration in fraud.event.handler.sas.field-mappings.response.purchase:

{
    "fraudResult": "FRAUD", //enum calculated by handler
    "detail": "{\"outcome\":\"F\",\"message\":\"Fraud detected\"}" //any json based on response config
}