[EPIC] Demonstrate the feasibility of a mojaloop fraud risk management solution using only open source components

[JustusOrtlepp]

Description

For a Mojaloop FRM solution to adhere to the same guiding principles as the Mojaloop platform, Mojaloop FRM must be constructed using open source software (OSS) components to minimise the implementation and operational cost of the platform. There are many potentially suitable OSS components available to meet the requirements of an FRM solution. The purpose of this epic is to design an FRM architecture out of OSS components and to evaluate the architecture against the FRM requirements as a Proof of Concept, before proceeding with the development of an FRM MVP for deployment.

For Mojaloop Hub Operators who perform the switching of transactions between DFSPs the Mojaloop Fraud Risk Management solution is a discrete extension to the Mojaloop switching platform that evaluates every transaction passing through the switch for fraud and money-laundering behaviour unlike current commercially available solutions our solution will be composed exclusively out of Open Source Software components and presented as a composite OSS Fraud Risk Management solution that can be deployed under an Apache 2.0 software license

Initiative / goal

The development and proliferation of Mojaloop is guided by the Level One Design Principles to support the establishment of financial services for the world’s poorest to use to build more prosperous and secure lives for themselves, their families, and their communities.

The focus areas of this strategy are:

1. Pro-poor, highly interoperable payments infrastructure
2. Increasing the use of digital financial services
3. Regulation and risk management
4. Driving women’s financial inclusion and economic empowerment

The development of Mojaloop has been guided by a number of these strategic drivers. The Fraud Risk Management value stream aims to extend the Mojaloop software with additional features specifically aimed at improved Fraud Risk detection and management, fulfilling the more detailed aspects of the strategy such as reliability, trust, and assisting authorities in the supervision and regulation of their financial services industries.

Hypothesis

1. The FRM product can be entirely composed out of open source software components for a total acquisition cost of $0. The acquisition cost does not include the cost of development, implementation, infrastruction or operations.
2. The selected open source components will be able to meet the requirements of a Mojaloop Fraud Risk Management solution.

Acceptance criteria and must have scope

Acceptance criteria:

1. Successful processing of an end-user against a block-list to block a transaction
2. Successful processing of an end-user against an allow-list to allow a transaction
3. Successful fraud risk evaluation of all incoming transactions into the platform
4. Successful entity resolution of all end users based on available personal information
5. Successful detection of 5 fraud typologies within the transactions
6. Successful listing of a resolved customer on a block-list when fraud is detected in a transaction
7. Successful detection of 3 AML typologies with the transactions
8. Successful detection of 2 internal (hub) fraud typologies within the transactions
9. Successful generation of a fraud alert via API egress for all detected typologies

Must have scope: Performant data pipeline to ingest transactional data from the Mojaloop platform Evaluation of all transactions against rules hosted in a rules engine

Leading indicators

Interoperability challenges between software components Large volume of undocumented featrures

Nonfunctional requirements (NFRs)

1. 35ms turnaround time
2. 3000TPS throughput

Stakeholders

• The FRM workstream, including the workstream lead
• The Mojaloop Product Manager
• Mowali
• Bank of Tanzanie (TIPS)
• The Bill & Melinda Gates Foundation (Matt Bohan/Miller Abel)
• Coil (PISP)
• Crosslake (PISP)
• Google (PISP)
• ModusBox
• Sybrin
• Code Quality/Security workstream

Timeline, resources, potential blockers

Timeline Delivery/Demo of the PoC is targeting the Mojaloop convening in January 2021.

Resources An agile team, consisting of:

• 1 product owner/manager (fraud)
• 1 or more developers
• 1 solution/system architect
• 1 shared resource from mojaloop/project for guidance/support on Mojaloop architecture and integration

Potential blockers

• Component knowledge: Do we know the components well enough to implement them effectively, and/or are the components supported well enough with documentation and active support from their communities to skill up quickly?
  • Interoperability of components: Can the components that we've selected work with each other well enough to be orchestrated into the FRM solution?
  • Component features fit: Do the components we've selected offer the features and functionality that we require?
  • Resourcing (funding, recruitment, contracting): Are the necessary contracts for funding and resources in place for us to start building and developing the solution?

[JustusOrtlepp]

Add acceptance criteria for the tracking of the cost of scaling the architecture to identify the resource consumption/requirement by component so that we can understand the impact of any given component on the overall cost of operation.

[JustusOrtlepp]

Add acceptance criteria for each component to be able to track the resource use and turnaround time/throughput for its operation.