Channel conceptual overview

Overview

The Actio Financial Crime Risk Management Solution is designed to provide scalable and extensible financial crime risk monitoring and management functionality as a service to connected client systems.

Channels can be implemented to allow for:

Resource optimisation - more expensive resources to be allocated for higher priority tasks, and low cost resources for typologies that can be deferred for a few hours or
Rules simplification - for groupings of typologies such as interdicting typologies (typologies requiring an urgent Go/No Go decision)

Figure 1: Actio Financial Crime Risk Management Solution - Generic Service Pattern

Figure 1 illustrates the high-level end-to-end system flow for the evaluation of data for financial crime risk and management purposes. The fundamental conceptual flow is laid out in the first row (1), and the flow for the transaction monitoring service is laid out in the second row (2). In broad and generic terms:

An authorised client system will submit data to the Actio platform for review using the Actio Transaction Monitoring Service (TMS) API and specifying the correct RESTful method (1a)
On receipt of the data via the appropriate secure endpoint, the Actio API will validate the incoming data to ensure it meets the minimum criteria defined for the service request (1a)
After validation and acceptance of the incoming data, the data passes through a data preparation flow within NiFi (1b) to prepare the data for processing by:
1. (Optional) Enriching the incoming data with additional data from internal and/or external data sources that support the requirements for rule processing
2. (Optional) Transforming the incoming data with generic routines that can be executed once up-front but utilised multiple times down-stream
3. Pseudonymisation of selected Personally Identifiable Information (PII)
4. Disambiguation of customer entities through an entity resolution process
5. Transformation of the incoming messages into a network of transactions, accounts and account-holders, captured in a graph database
6. Persistence of the enriched, pseudonymised and disambiguated messages to the transaction history database to facilitate historical data queries in support of rule execution
Once data preparation is complete, messages will be passed to the channel router and setup processor (CRSP) (1c). The CRSP will interrogate the message and determine its type and from there, determine which rules and typologies to invoke to evaluate the transaction message. The CRSP will pass the transaction message to all require rules, across any number of configured channels.
Each channel will contain a number of rule processors encapsulated in the logical channel to match the function-specific objectives of each channel. The incoming data will be routed to the relevant rule processor and through the combined effect of the rule processing (1d), the rule results will be aggregated and evaluated against financial crime risk metrics within a typology processor. (1e) If optional interdiction has been enabled and a typology alert is triggered, the output can be forwarded through an egress API to workflow services or a case management system, as determined by an implementer, for the transaction to be interdicted (blocked) and investigated.
The net effect of the evaluation of the typologies within the various channels must be determined by aggregating the channel results into a summarised result within the Channel Aggregation and Decisioning Processor (CADProc). The various channel results are then passed on for the final consolidation within the Transaction Aggregation and Decisioning processor (TADProc) where an over-arching and summarised result is calculated for the incoming transaction. (1e)
Any actions that are to be taken based on the results of the evaluations, can be output to a case management system workflow or egress API for processing, and the results stored with the original transaction. (1f). In the case of the Channel Aggregator and Decisioning Processor this can also be configured to provide a go / no go decision for a transaction in a specific channel.

Transaction Monitoring for Financial Crime Risk

The Actio platform MVP is focused on providing a Transaction Monitoring Service for an instant payment switch Operator such as the open source software platform, Mojaloop.

The transaction monitoring service aims to evaluate all transactions submitted by a client system, such as Mojaloop, to determine the financial crime risk associated with those transactions. Other payment systems have been factored as part of a generic and open design and architecture, but an implementation is solely focused on a Mojaloop implementation. A submitted transaction flows through the solution as follows:

2a

The client system will submit the transaction data to the Actio Transaction Monitoring API and request a full financial crime risk evaluation, including list evaluation, fraud evaluation and money-laundering evaluation.

The API will authenticate the request.

The API will validate the transaction data to ensure that it meets the minimum requirements for a successful evaluation.

2b

The data will be enriched with additional data that is required for the evaluation, but was not submitted with the transaction data itself. Examples of the type of enrichment may be:

Determining a unique identifier for all participants in the transaction through an Entity Resolution process.
Looking up the geographical region associated with the IP address of the payer involved in the transaction.

The data may also be transformed if there are specific transformations that could be performed once for the benefit of multiple later processes. The intention with transformation during this step is largely to optimise performance.

Note: All validation of the data is intended to take place in the Transaction Monitoring Service API and is not expected to be repeared during the data preparation step. Similarly, data is expected to already be submitted in the appropriate format for each data field and reformating of the data is also expected to be unlikely at this step.

2c

The transaction router will determine which channels are to be invoked to fulfil the transaction monitoring service request and will then route the transaction to each of the selected channels.

For the Actio MVP, we are proposing 3 channels:

A high-speed channel intended to be able to interdict (block) transactions pre-settlement (“in flight”) with an SLA commitment of 35 miliseconds.
A medium-speed channel intended to flag transactions post-settlement on suspicion of fraud, with an SLA of 1 hour.
A low-speed channel intended to flag transactions post-settlement on suspicion of money-laundering, with an SLA of 24 hours.

Note: With reference to the high-speed interdicting channel: while this is not an explicit requirement for Mojaloop, the capability to interdict a transaction is a key critical success factor for the viability of any transaction monitoring solution, which is why we are including it in the MVP. Having said that, there should be no structural or technnical differences in the implementation of an interdicting channel as opposed to the other two (non-interdicting) channels; the differences should be in the configuration of the channels only.

Figure 2: Actio Financial Crime Risk Management Solution - TMS Channels

Figure 1: 2d

Figure 2 illustrates the layout and contents of the transaction monitoring service channels:

The Channel Router & Setup Processor (CRSP) will determine which rules and typologies to invoke to evaluate the transaction. The rules are associated with specific typologies and typologies are grouped into one or more logical channels. The CRSP will route the transaction to the rules in such a way that a rule will only be executed once across the platform.
1. Each of the channels follow the same basic design pattern that includes the following components:
  1. Not every transaction is required to be evaluated by every available rule in the platform. Performing evaluations unnecessarily will waste processing time and increase the cost of operating the platform. The purpose of the Channel Router Setup Processor (CRSP) is to determine which rules are to be executed in the channel for the current transaction. The alignment of rules and typologies to channels is defined through configuration, via a network map that is interpreted by the CRSP before invoking the required rules.
    1. The CRSP will interrogate the network map to determine the rules and typologies to invoke.
    2. The CRSP will de-duplicate the rules to ensure that every unique rule is invoked only once.
      1. A rule processor is considered unique based on its combination of identity information (ID and version) and input parameters.
      2. The same rule processor (by ID and version) may be required by different typologies with different parameters. In such a case, the rule processor will be invoked multiple times: once for each different set of parameters.
    3. The CRSP will route the transaction to each of the required rule processors
The first proposed channel is a high-speed pre-settlement interdiction channel. The channel will be populated by rules and typologies that define high-risk activities that may result in the transaction being interdicted.
The second proposed channel is the post-settlement fraud evaluation channel. The channel will be composed out of different rules and typologies, but the over-all flow and functioning of the channel will be similar to the pre-settlement fraud evaluation channel.
The third and last channel contains rules and typologies to identify money-laundering behaviour. While the rules and typologies are different in this channel, the flow and functioning is similar to the fraud channels, with one notable exception: it is unlikely to be necessary to trigger any urgent alert response process out of typologies in this channel and also since this channel is likely to complete its evaluations long after the fraud channels due to deep historical data modelling and analysis, any workflow action triggered in this channel can be deferred to the Transaction Aggregation and Decisioning Processor.
Each rule processor evaluates the submitted transaction and resolves to a boolean (True or False) result that is then passed to the typology processor.
The typology processor aggregates the rule results according to an external typology configuration and functions as a business rules engine in its own right. Only a single typology processor is required in the platform and the typology processor
1. Receives rule processor results from all rule processors
2. Determines when typologies have received all their rule results, as defined in the individual typology configurations
3. Scores each typology according to the rule results and the typology configuration
4. (Optional) Evaluates the typology result against a threshold defined in the typology configuration and generates an interdiction and alert if the threshold is breached.
5. When a typology processor has completed the calculation of the typology score, the typology result is submitted to the Channel Aggregation and Decisioning Processor.
The purpose of the Channel Aggregation and Decisioning Processor (CADProc) is twofold:
1. Evaluate typology processor results as the results are delivered by the typology processor and trigger an immediate “go” action to the client system if the client system is awaiting an interdiction outcome. The “go” decision is defined based on the collective non-interdicting outcomes of a set of typologies and is defined in the channel configuration. The “go” decision can be presented to the client system before all the typologies in the channel had been completed. For example, if the debtor in a transaction is in an allow-list, the transaction can proceed regardless of the outcomes of any of the other typologies in the channel.
2. Track the conclusion of all typology processors in the channel and combine the typology processor results into a final channel result that is routed to the Transaction Aggregation & Decisioning Processor.

Figure 1: 2e

Similar to the Channel Aggregation and Decisioning Processor, the Transaction Aggregation and Decisioning Processor (TADProc) has the following two major functions:

Track the conclusion of all channels that had been invoked for the transaction evaluation and combine the channel results into a final definitive transaction result
Evaluate the transaction result and trigger final alert processes if required.

If interdiction is implemented, the Typology Processors will be able to generate alerts based on threshold breaches defined for each typology, but in the absence of an interdiction approach, the TADProc will review the transaction result holistically and generate a Fraud or Money Laundering alert if any of the typologies that had been evaluated for the transaction had breached its defined threshold.

Figure 1: 2f

The final step in the transaction monitoring service process is to take any required actions that may result from the various evaluations of the transaction.

These actions may, for example:

direct a Case Management System to conduct an investigation into the transaction and/or its participants
add a participant to a watch-list for more strict evaluation of future transactions
generate a suspicious transaction report (STR) or suspicious activity report (SAR) to be submitted to a regulator

On the conclusion of this final step, the transaction monitoring service responsibility towards the client system ends, though if any risk management processes were triggered, these would now have to be managed operationally in a Case Management Solution of some kind.