Skip to content

FRMS Actio Proof of Concept

This entry is part 3 of 4 in the series Musings from an Open Source Squad

The Team at INFITX has recently built a Proof of Concept build around the OSS (Open Source Software) FRMS Actio Platform

Vijay Kumar & Miguel de Barros, have had the privilege of working on the Mojaloop OSS (Open Source Software) project as part of the Core Engineering team, in conjunction with the broader community to develop and maintain Mojaloop’s Core and Testing components. And also integrating the Mojaloop Switch into several different platforms, such as the FRMS Actio Platform as part of this Proof of Concept.

Objectives
  1. Deploy & configure the FRMS Actio Platform on Amazon Elastic Kubernetes Service (EKS),
  2. Deploy & integrate a Mojaloop Payment Switch using the FRMS’s Mojaloop Payment Platform Adapter (PPA) to have Mojaloop Transfer events processed by Typology 28,
  3. Develop and integrate a simple custom “Hello World” Sanction Screening Rule that we plan to enhance in the future to interdict live transfers on the Mojaloop Payment Switch,
  4. Configure a modified Typology 28 to include our custom “Hello World” Sanction List Screening Rule,
  5. Use an OSS Customer Relationship Platform (CRM) Platform to capture Actio’s reports/alerts produced by the Case Management Processor output from processing Typology 28.

We would like to share some of the details around this PoC with you, touching on the infrastructure, and typologies in the development of our custom rule.

But first some disclaimers: 

  • “Actio” is a working title for the FRMS Platform developed by the FRMS COE (Centre of Excellence) and its wider community and is subject to change,
  • Sensitive information in this blog has been redacted in several figures/screenshots below as requested by the FRMS COE.

Infrastructure Overview

We deployed both the FRMS Actio Platform and the Mojaloop Payment Switch within a single Kubernetes cluster, partitioned by several namespaces as shown in the following figure:

Click to expand

This was done for several reasons, but mainly to simplify the infrastructure deployment which also had the added benefit of simplifying the connectivity details.

This environment was provisioned using the excellent EksCtl tool, which drastically simplified the configuration of AWS’s EKS, VPCs, Subnets, Policies, etc. It proved to be the perfect tool to provision a Kubernetes cluster quickly and efficiently for a PoC such as this.

A “PoC” Fraud Detection Story

We decided to utilize the existing Typology 28 “False promotions, phishing, or social engineering scams” for this PoC, with some modifications:

  1. We reduced the Typology footprint by removing several rules that tend to easily “breach” the Typology. However, we could have alternatively tweaked the weights of these rules to reduce their impact. Regardless, we wanted the PoC to be focused on the outcome of the next point,
  2. Added a custom “Hello World” Sanction Screening Rule that we referred to as Rule 501.

Click to expand

Custom Rule 501 – Sanction List Screening

The custom “Hello World” Sanction Screening Rule implements a simple comparison against an in-memory Sanctions List The rule will compare the debtor name (i.e. first name, last name, etc) found in the Mojaloop Transfer on all completed transfers.

The reason we decided to implement such a rule, is that Sanctions screening plays a crucial role in preventing financial crimes and ensuring compliance with AML laws and regulations. Blocked persons are not allowed to conduct financial transactions, and companies that violate sanctions can face serious financial and reputational consequences.

If we were to productionalize such a rule, we would make several key enhancements going forward:

  1. Integrate Rule 501 into a real-time interdicting Typology to halt Transfers during the Mojaloop Agreement (i.e. Quote) phase,
  2. Enhance the “Screening” logic to resolve an “Entity” not just by their names, but by utilizing several data points (e.g. Date of birth, Address, etc) in conjunction with a KYC datastore, and even perhaps include credit records.

Configuration

The following figure shows the FRMS Actio configuration for the custom “Hello World” Sanction Screening Rule, otherwise referred to as Rule 501.

Here you can see that we have two sub-rules defined for each use case with an appropriate description:

  1. “.00” is the sub-case where no debtor match is found when compared to the Sanctions List
  2. “.01” is the sub-case for when a debtor match is found when compared to the Sanctions List

Click to expand

The next config shows the expression definition for Typology 28, where we set the weight of each rule and how the rules should be aggregated. In this use case, we have set Rule 501 to have a weight of “100″.

Click to expand

In the following figure, we have defined the overall Transaction configuration which includes an association between:

  1. The triggering event, here being the pacs.002.001.12 message that is produced by the Mojaloop Payment Platform Adapter;
  2. The channel definition which includes a link to Typology 28; and
  3. The overall Threshold for Typology 28, which is set to “75”.

This means that once all the weights of the rules are aggregated (i.e. added together) into a value, this value can be compared against the Threshold set below (i.e. “75”). If the aggregated value is larger than the Threshold value, then we have a breach of the Typology which should trigger a potential fraud alert for further investigation.

Click to expand

Test Scenarios

We tested our custom Rule 501 (Sanction List Screening) with the two following scenarios:

Scenario 1:

A transfer with the payer name as “James Smith” who is not listed in the sanction list. Hence we expect a clean FRMS report, showing that all Rules returned a result of “false”.

Click to expand

In the above screenshot, you can see the report status is “NALT” (Arrow #1) which means the report is clean (i.e. No Alert). Because the typology threshold is “75” (Arrow #3) and the result is “0” (Arrow #2). That means the typology score has NOT exceeded the threshold, hence no alert.

You can also observe the individual rule results, particularly for Rule 501 (Arrow #4 & #5) with the result “false”.

Scenario 2

A transfer with payer name as “John Doe” who is listed in the sanction list. So we expect an “ALERT” in the FRMS report.

Click to expand

In the above screenshot, you can see the report status is “ALRT” (Arrow #1) which means the report is not clean (i.e. Alert). This time the typology result is “100” (Arrow #2) which exceeds the threshold of “75” (Arrow #3) and hence there is an alert.

You can observe that the result of Rule 501 (Arrow #4 & #5) (If we refer to the configuration of the Typology in the previous section, this Rule has a weight of “100”) to the overall Typology score as the payer name was found in the sanction list.

Test setup for making a transfer

For making a transfer through mojaloop, we used Mojaloop Testing Toolkit (TTK) that comes with a Mojaloop Helm deployment. TTK simulates both Payer (i.e. Debtor) and Payee (i.e. Creditor) DFSPs (Digital Financial Service Providers) and we can use the “Mobile Simulator” page in TTK for triggering a successful transfer.

Following are two screenshots of the TTK Mobile Simulator UI showing a transfer being sent from the Payer’s DFSP (i.e. Pink Bank) to the Payee’s DFSP (i.e. Green Bank):

Click to expand

Click to expand

We can also set the Payee’s name using the settings screen in the “Mobile Simulator” as shown below. We tested the rule using different payer names using this option based on the two scenarios described above.

Click to expand

If you are interested in finding out more about the Mojaloop Testing Toolkit (TTK), then we recommend having a look at this blog post by TTK’s main developer, Vijay Kumar Guthi – “Get Hands-On Locally with Core Mojaloop”.

Conclusion

In doing this PoC, we achieved the objectives that we set out for ourselves, namely:

  1. Proving that we can deploy & configure the FRMS Actio Platform on Amazon Elastic Kubernetes Service (EKS),
  2. Integrating a live Mojaloop Payment Switch using the FRMS’s Mojaloop Payment Platform Adapter (PPA) into a working FRMS Actio Platform,
  3. Developed & Integrated a custom “Hello World” Sanction Screening Rule, i.e. Rule 501,
  4. Configured Typology 28 to include Rule 501s as part of its aggregation results, and
  5. Lastly, we showed how we can capture Actio’s report using an OSS CRM-based system.

In addition, we were also able to contribute valuable learnings and recommendations to the FRMS Actio Project, specifically around the deployment documentation, and provide key suggestions around how the deployment experience could be improved and simplified based on our experience in packaging Mojaloop Helm Releases and developing the Mojaloop IaC Platform.

Keep an eye out for a further enhancement of this PoC, as we plan to integrate the FRMS Actio Platform into the Mojaloop Payment Switch to allow for real-time interdictions of Transfers based on fraud alerts.

A special thanks to the FRMS Centre of Excellence (COE), Sybrin, and the wider community in supporting us in this endeavor, with shout-outs to the following individuals:

  • Justus Ortlepp
  • Johan Foley
  • Kyle Vorster

If you are interested in learning more or looking for technical support regarding Mojaloop with FRMS transaction monitoring, then please contact us.

And lastly, If you are interested in learning more about the technical aspects of Mojaloop, then we recommend having a look at Miguel de Barros’s guide on “Getting Started as a Mojaloop Developer”.

References

  1. https://frms.io
  2. https://github.com/frmscoe
  3. https://frmscoe.atlassian.net/wiki/spaces/FRMS/pages/6488065/Product+Overview
  4. https://mojaloop.io
  5. https://github.com/mojaloop/ml-testing-toolkit
  6. https://aws.amazon.com/eks/
  7. https://eksctl.io
  8. https://www.infitx.com/devs-get-hands-on-locally-with-core-mojaloop
  9. https://www.infitx.com/getting-started-as-a-developer
  10. https://github.com/mojaloop/documentation-artifacts/blob/d5fbeafedfd66b4484a8d6dd673087e28696b045/presentations/pi_19_july_2022/presentations/Mojaloop%20PI-19%20FRMS.pdf

Contact the INFITX Team