Versions Compared

Old Version 1

changes.mady.by.user Rob Reeve

Saved on

compared with

New Version 2

changes.mady.by.user Johan Foley

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

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)

Drawio
zoom1
simple0
inComment0
pageId4140895331740263
custContentId6396969126586464
lbox1
diagramDisplayNameActio Conceptual Design.drawio
hiResPreview1
contentVer1
revision23
baseUrlhttps://lextegofrmscoe.atlassian.net/wiki
diagramNameActio Conceptual Design.drawio
pCenter0
width1264.494899999999998
links
tbstyle
height420.9999999999999486

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:

  1. An authorised client system will submit data to the Actio platform for review using an appropriate Actio service the Actio Transaction Monitoring Service (TMS) API and specifying the correct RESTful method (1a)

  2. After authenticating the request, and on 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)

  3. After validation and acceptance of the incoming data, the data passes through a number of data processors data preparation flow within NiFi (1b) to prepare the data for processing by:

    1. Predominantly enriching (Optional) Enriching the incoming data with additional data from internal and/or external data sources Also transforming 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

    Once prepared, the data

    2. Pseudonymisation of selected Personally Identifiable Information (PII)

    3. Disambiguation of customer entities through an entity resolution process

    4. Transformation of the incoming messages into a network of transactions, accounts and account-holders, captured in a graph database

    5. Persistence of the enriched, pseudonymised and disambiguated messages to the transaction history database to facilitate historical data queries in support of rule execution

  4. Once data preparation is complete, messages will be passed to a data router (1c) that will split the data among a number of function-specific evaluation 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.

  5. 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 data rule results will be aggregated and evaluated against financial crime risk metrics within a typology processor. (1d)The nett effect of the evaluations (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.

  6. 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 related to is calculated for the incoming data as a wholetransaction. (1e)

  7. Any actions that are to be taken based on the results of the evaluations, must then be triggered by the platform. (1f)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 will be is focused on providing a Transaction Monitoring Service for a Hub an instant payment switch Operator such as the open source software platform, Mojaloop.

In figure 1, this service (2) encompasses the components 2a through 2f as the first expression of the fundamental conceptual design (1) outlined in the overview above.

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:

...

Drawio
zoom1
simple0
inComment0
pageId3004825611740263
custContentId3004499386520907
lbox1
diagramDisplayNameActio TMS channels v2.drawio
contentVer1
revision12
baseUrlhttps://lextegofrmscoe.atlassian.net/wiki
diagramNameActio TMS channels v2.drawio
pCenter0
width1524.33333333333281523
links
tbstyle
height764.33333333333366999999999998

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:

  1. The transaction router Channel Router & Setup Processor (CRSP) will determine which channels rules and typologies to invoke to evaluate the transaction. The rules are associated with specific typologies and will then typologies are grouped into one or more logical channels. The CRSP will route the transaction to the selected channels.There are currently 3 channels proposed for the MVP. The first of these is the pre-settlement fraud evaluation channel. 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

        call the typology processors that are deployed in the channel

        1. interrogate the network map to determine

        which rules must be processed for those typologies

        1. the rules and typologies to invoke.

        2. The CRSP will

        normalise

        1. de-duplicate the

        list of

        1. rules to ensure that every unique rule is invoked only once.

      2. The CRSP will route the transaction to each of the rule processors, along with the list of typologies that will require results from the invoked rule processors

      Each rule processor evaluates the submitted transaction and resolves to a boolean (True or False) result that is then passed to each of the typology processors that needs the result.

          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.

    2. Each typology processor contains a list of the rules (and any typology-specific parameters) required for the typology to evaluate the transaction against a specific fraud scenario and will provide this list to the CRSP when requested. A typology processor will combine the results of its rules into a typology score as the rule results are delivered by the rule processors invoked by the CRSP. When a typology processor has completed the calculation of the typology score, the score is scubmitted to the Channel Aggregation and Decisioning Processor.

    3. The purpose of the Channel Aggregation and Decisioning Processor (CADP) is twofold:

      1. Evaluate typology processor results as the results are delivered and trigger interrim alert processes if required

      2. Track the conclusion of all typology processors in the channel and combine the typology processor results into a final definitive channel result

    4. If any single typology processor result breaches a set threshold or specific alert conditions, the CADP will directly trigger the appropriate process to act on the result. For example, if a typology indicates that a transaction should be interdicted, it is best to notify the client system as soon as this outcome is known.

    The second

        1. The CRSP will route the transaction to each of the required rule processors

  2. 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.

  3. 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.

  4. 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.

  5. Once a channel has completed the aggregation of the typology results within the channel, the channel will route the results to the Transaction Aggregation and Decisioning Processor (TADP).

  6. .

  7. Each rule processor evaluates the submitted transaction and resolves to a boolean (True or False) result that is then passed to the typology processor.

  8. 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.

  9. 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 (TADPTADProc) has the following two major functions:

  1. Track the conclusion of all CADPs channels that had been invoked for the transaction evaluation and combine the channel results into a final definitive transaction result

  2. 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:

  1. direct a client system Case Management System to conduct an investigation into the transaction and/or its participants

  2. add a participant to a watch-list for more strict evaluation of future transactions

  3. 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.

One final note on the method of communication employed in the design, in the absence of a formal queue-based publish/subscribe architecture:

A typology processor is configured with the list of rules to execute to evaluate a specific fraud scenario and it is necessary for the Channel Router Setup Processor (CRSP) to retrieve this list of rules from the typology processors to invoke the necessary rules. Subsequently, it is not necessary for the function call to the rules to include a list of the neighbouring rules so that this information can be passed to the typology processors as a “checklist”, since the list of rules came from the typology processor in the forst place.

For the Channel Aggregation and Decisioning Processor (CADP) and the Transaction Aggregation and Decisioning Processor (TADP), the approach is slightly different. The CADP and the TADP do not know up-front which typologies and which channels are expected to be invoked. To communicate this information down-stream from the Transaction Router and Channel Router, the following approaches can be considered:

  1. Forecasting approach: When a (Transaction or Channel) Router submits the transaction to the channels, the router can also invoke the (Transaction or Channel) Aggregation and Decisioning Processor with a list of the invoked processors and the ADP can then create and maintain a checklist to monitor the delivery of expected incoming results.

  2. Shotgun approach: When a (Transaction or Channel) Router submits the transaction to the channels, the router will include the list of all adjacent processors in the function call. When a processor delivers its result to an (Transaction or Channel) Aggregation and Decisioning Processor, it will also supply the list of the adjacent invoked processors and the ADP can then use this list as a checklist to monitor the delivery of expected incoming results.

  3. Polling approach: This is the current method employed by the Channel Router and Setup Processor to engage the rules and typology processors. The CRSP will determine which typologies to invoke and then request the list of rules from each target typology. The CRSP will invoke the rules and the rules will pass their results to each typology processor. The typology processors will directly the delivery of expected incoming results against the internal list of rules.

...

Case Management Solution of some kind.