Mojaloop integration into the Actio FCRMS

[JustusOrtlepp]

Request Summary:

Actio is under development as a Financial Crime Risk Management Solution to provide real-time transaction monitoring services for transactions routed through a Mojaloop hub. As such, it is essential that Actio is able to receive the following messages from Mojaloop, in real-time, when these message are routed out of Mojaloop to their respective target DFSPs:

• POST /quotes
• PUT /quotes
• POST /transfers
• PUT /transfers

Actio is designed to be an ISO 20022 compliant platform and has developed a Payment Platform Adapter for converting messages in a Mojaloop format into messages in a suitable ISO 20022-compliant format. The purpose of this request is to introduce a mechanism whereby Mojaloop messages can be routed to the Actio Payment Platform Adapter from Mojaloop simultaneous with (or as soon as possible following) the routing of the message to the target DFSP.

Request Details:

Deadline: Development to commence from August 2021 Impact (Teams): Mojaloop Core Impact (Components):

• Kafka (Event Stream) topic-events
• Mojaloop DMZ
• Mojaloop firewall

Mojaloop currently utilises Kafka in support of a pub/sub architecture to route message and event traffic inside and out of the platform. The Mojaloop implementation of Kafka includes the Kafka events topic "topic-events" that logs, among other events, the Mojaloop transaction messages required by the Actio platform for transaction monitoring.

We would like to create a consumer of the topic-events events topic to as a listener service attached to the Actio Payment Platform Adapter. The listener would monitor events posted to the topic for one of the following messages:

• POST /quotes
• PUT /quotes
• POST /transfers
• PUT /transfers

If one of these messages are logged, the listener would pick up and route the message to the Actio Payment Platform Adapter for processing (transformation of the message to an ISO 20022 format) and routing to the Actio Transaction Monitoring Service API.

We also recommend to locate the Payment Platform Adapter within the Mojaloop DMZ as a third-party vendor application to "shorten the distance" between the listener and the PPA. The PPA would then function as an egress API, otherwise the listener would require its own egress API and duplicate that part of the functionality provided by the PPA already.

Artifacts:

• [ ] Artifact to consider [@Contributor]
• [ ] Detailed presentation attached, and intended to be presented to the Design Authority LexTego - Mojaloop to Actio interface 20210713.pptx
• [ ] Updated presentation based on DA feedback at initial review: LexTego.-.Mojaloop.to.Actio.interface.v2.20210715.pptx

Dependencies:

• [ ] If Applicable

The proposed solution is intended to be as non-invasive as possible and aims to be implemented alongside existing Mojaloop functionality and services. No dependencies have been identified.

Accountability:

• Owner: Justus Ortlepp
• Raised By: Justus Ortlepp

Decision(s):

Favourable review by present members of the Design Authority. Decision to defer approval once all members of the DA have had an opportunity to review and reflect.

• Approved By:

Details

• [ ] The forum recommended that a listener be created as a Mojaloop core function to consume events from the topic-events topic and publish the messages required by Actio on an Actio-specific topic. This serves to limit indiscriminate access by Actio to all events and only make available the events that Actio specifically requires. The Payment Platform Adapter would then listen to the Actio-specific topic. The Actio team will update the design proposal accordingly.

Follow-up:

• [ ] All members of the DA to review and reflect on the amended proposal in anticipation of a final decision once all (or sufficient) members are present.

• [ ] Actions to implement the decisions

[pedrosousabarreto]

@JustusOrtlepp @johanfol I suggest we specifically call this as outbound integration. Otherwise, looks great.

[johanfol]

s

[johanfol]

This outbound integration design presented to DA on 25 May 2022, as follows: FRMS to build proposed Payment Platform Adapter (PPA) that will subscribe to the Kafka topic: "topic-events", filter out the applicable messages (Quote, Quote Response, Transfer, Transfer Response), and send it off to the Actio FRMS for evaluation via a Rest call to FRMS. The PPA will, with other words, be inside of the DMZ to access Kafka, with the rest of the FRMS platform living on its own, separate infrastructure without any connection to the Switch.

Additional Info (subject to change): To filter the correct events, the following filter suggested to be applied to the messages in the Kafka topic to retrieve appropriate messages (could be updated if necessary):

• ML POST Quote -> value.metadata.trace.service == "qs_quote_forwardQuoteRequest" && value.metadata.event.action == "egress" && value.metadata.trace.tags.transactionType == "quote" && value.metadata.event.type == "audit"
• ML PUT Quote Reply -> value.metadata.trace.tags.transactionType == "quote" && value.metadata.trace.tags.transactionAction == "fulfil" && value.metadata.trace.service == "qs_quote_forwardQuoteUpdate" && value.metadata.event.action == "egress"
• ML POST Transfer -> value.content.method == "POST" && value.metadata.event.type == "audit" && value.metadata.event.action == "egress" && value.metadata.trace.service == "ml_notification_event"
• ML PUT Transfer Reply ->value.content.method == "PUT" && value.metadata.event.type == "audit" && value.metadata.event.action == "egress" && value.metadata.trace.service == "ml_notification_event"

DA Attendees (please confirm approval of the design by commenting "Approved"): @MichaelJBRichards
@elnyry-sam-k
@mdebarros @PaulGregoryBaker @pedrosousabarreto Bryan Schneider @johanfol

[mjbrichards]

Approved

[pedrosousabarreto]

Approved