Mojaloop FRM playback

Thursday October 22, 2020
1:30 PM UTC

Session Leads: Sudhir K Upadhyaya (@Sudhir), Justus Ortlepp, Greg McCormick (@gm-sybrin)

Session Description:

  1. Review of Internal Mojaloop Fraud risk typologies
  2. Outline and scope of a Proof of Concept using only open source components
  3. Overview of the open source architecture for a Mojaloop FRM solution

Session Slides:

Session Recording:

Please post questions, suggestions and thoughts about this session in this thread.

Post by clicking the “Reply” button below.

Chat from Sudhir’s presentation on typologies:

06:44:07 From Miller Abel : Velocity limits can be implemented by the DFSP… you can’t then aggregate enough of these random probes with declining to proceed. The hub might do this, but only on the quotation flow, which is not always intermediated by a hub or scheme.
06:45:42 From Miller Abel : These kinds of probes for name could be flagged by the hub as part of a fraud score with action taken by either receiver DFSP or sender DFSP or both.
06:45:52 From Justus Ortlepp to Panelists : You’ll also have to build up this perspective over time. There may be the occasional, legitimate cancellation and you’ll have to evaluate transactions against thersholds and identified patterns in the data.
06:47:10 From Justus Ortlepp to Panelists : One additional advantage of doing this at the hub level is to identify when it is the DFSP itself perfoming the snooping, and not a syndicate operating through one or many (innocent) DFSPs.
06:52:31 From Lesley-Ann Vaughan to Panelists : I have sent a huge number before now to get the data back when I worked at a business paying salaries in bulk - because declined transactions were free and I wanted them to fail but still get the information
06:52:34 From Lesley-Ann Vaughan to Panelists : :slight_smile:
06:53:11 From Lesley-Ann Vaughan to Panelists : i think your idea of enrichment is the right route
06:53:48 From Miller Abel : @Leslie-Ann, our bulk transfer engine allows this use case directly, without requiring the work-around you are suggesting! And then we know it’s institutional and we know who is initiating the requests.
06:54:08 From Lesley-Ann Vaughan to Panelists : exactly - and that’s a good differentiator potentially, @Miller.

Chat continued…

06:58:44 From Samuel Kummary : Virtual applause - Justus!
06:59:07 From Philip Helberg : :clap::clap::clap::clap::clap::clap::clap::clap::clap::clap:
06:59:32 From Simeon Oriko : FRM Github:
06:59:39 From Sudhir K Upadhyaya to Panelists : great job Justus
06:59:40 From Samuel Kummary : Getting a new label “oss-frm” for your issues :slight_smile:
07:03:50 From Lesley-Ann Vaughan : to make it demonstrable - thought about integrating for case management?
07:09:11 From Simeon Oriko to eric meniere, All Panelists : Hi Eric. I see your hand up. Do you have a question?
07:11:13 From David Mangini to Panelists : Is there compliance in the Data Pipeline for Fraud/Risk for GDPR and “Right to be Forgotten”?
07:12:21 From eric meniere to Panelists : Hi, will you make this recording available later on?
07:12:44 From Simeon Oriko to eric meniere, All Panelists : Yes Eric. We will.
07:16:00 From Michael Richards to Panelists : Not JSON, I think…
07:19:59 From eric meniere to Panelists : Thanks!
07:24:34 From Terracia King to Panelists : Thank you all for using Discourse.Please post questions and comments on this FRM session here: Mojaloop FRM playback
07:25:44 From Greg McCormick : David we have allowances for GDPR etc in all of this, but it is an area that will require a lot of work.
07:27:45 From Miller Abel : @David, there are limits on GDPR “right to be forgotten.” In particular, the right does not extend to credit history…
07:28:03 Q: " Can I have my credit history deleted under the GDPR’s right to erasure?" … “No, you cannot simply have your credit history deleted.”
07:28:11 From Miller Abel :
07:28:47 From Miller Abel : So the GDPR design will be sensitive to use case and local regulation, no doubt!