 Okay, welcome everybody to creating an open-source fraud risk management system in order to close financial inclusion gap I'm Greg McCormick. I'll be the presenter today. I'm a member of the Mojloop Foundation technical governing board and I'm also I work for cyber and systems as a day job as a chief strategic strategic business development officer I Work for cyber and systems of the day job as a chief strategic business development officer What I want to talk to you today is about how to solve financial inclusion how to Take action But I want to talk to you today is about a journey that started years ago With the project called Mojloop. So that's what we see Mojloop Foundation and all over this stuff The idea was to build a central switch and that simple switch would Lower the cost of operations for for therefore ease financial inclusion and doing so and it's very expensive to run national switch It's also a lot of the techniques behind it our old real-time Didn't exist things like that. So we thought about to solve that problem and during that problem We also realized that we needed to solve the problem of fraud So very early on this was decided That there would be a fraud part of this project that really wouldn't be part of this project if Mojloop has Created its own foundation at this point in time and it's off on its own. That's you get some funding and things like that, but But but but how do we how did we go about that? We'll get to that in just a second So so first off, you know, we're all the different ways that we would improve financial inclusion Simplify access and improve the rules for accessing financial inclusion Right now, it's known that some of the FATQ rules the KYC processes that you hear about they're probably a little too stringent For People that don't have documentation if you don't have documentation you don't have an ID Therefore you don't have an identity. There's all I could go on and on about this They've been working on this problem for years with risk-based assessment models Increasing the access by creating more and better programs. So this is through Veterans from the Gates Foundation and and others That are seeking to add systems for financial inclusion throughout the world Reduce the friction of onboarding. So how do we make it easier for somebody to actually join a system? Which is everything from identity to also the process just making it simpler quicker and easier And then how to reduce the friction of using mojo loop the ease of use Because they are one of the areas that we're trying to do with that and in the interoperability So how do we make that switch work with other switches much more easily? So this is some of the problems that we've been trying to solve And more importantly, how do we reduce the cost right when we reduce the cost with open source software? So open source can't solve every problem. Sorry. It can't There are times where we're some good old commercial off the shelf Our resolutions need to be done Um, but the open source cost Costing structure certainly can drive the cost down on the overall solution And therefore something we wanted to let's look at Say and we wanted to remove the fraud costs from the system. So how do we look at that? We're really only just doing that mojo loop itself has been going on often I'm just going to say five years. I think it's been longer than I think it's eight But um, how do we reduce the cost of fraud in the system? And and we do that by obviously making an open source antifraud software, which we're going to talk about But also by making a better mousetrap by making a better system And a better system that is easier to be included in other people's solutions so that it can grab some Get some legs be planted. So, um, we got given the keys if you will and we got told to start from scratch and design from scratch And we were able to do that quite a bit and therefore we've got a very very good engine This is that underneath all this So we like to talk about this on living the life of someone earning less than two dollars a day I don't think I need to really go into an explanation of that but it's not very easy and So you kind of put yourself in the right crew of mind where we're really trying to help people At that end of the spectrum Just frankly join a system and and not to rip off because if they get ripped off if they fall to create a fraud It could be their life savings. They're decade savings. They're you know, it's it's horrible. It's a horrible situation So what is a digital public good? Um, it's something that we Uh, we believe is the key to achieving financial inclusion So there's lots of different fragments systems out there. Those are things we've been working on for quite a while 2007 Um, we eventually got to connected systems or how do we do interoperability between systems in uh, 2018? um But now we're starting to move beyond Just the idea of um, of a payment system being a digital public good or something that provides something That lends itself towards some sort of a payment. We're also seeing that we're we're we can you know stopping fraud stops expenditure We can pulls that out of the system and therefore in turn um You have a lower cost or lower barrier to get in so public good may actually be a lot broader And and yes, obviously public good can be any public good. But what we're talking about here We're talking about financial inclusive type goods and the fraud stuff can be a little bit different to uh to follow So mojo loop like I mentioned it transformed real-time payments. Um lower cost of capital upfront Lower maintenance cost because the effort is shared across many organizations No vendor lock in uh lower cost to acquire With additional functionality and things like that. So These are the same principles with that we are following with the open source software Lower cost of capital upfront lower maintenance costs, etc. Etc. So it's the exact same thing It's just that we're focusing on the fraud side of things Uh, the mojo loop community itself has grown to um about 1200 participants six continents 47 countries So we're hoping that uh, we'll we'll write on their coattails a little bit And think that we'll have the benefit of being able to do that But we are not restricted to be working with them at all. In fact, we don't want to be seen like that We don't want to be seen as a mojo loop project, which we are not we are a completely independent project Um, we're going to take it more of our wings. Uh, this year. Uh, basically we got the mbp got done this year We're going to create a center of excellence surrounding this and we're going to start defining it more in this year So what is um, what is fraud risk management system? What's the system for doing this in in general? Um, you know going back to the beginning of mojo loop, like I said, it was always envisioned. There would be some sort of anti fraud Uh, the first thing that was commissioned Was something that lovingly became to be called the thieves guy Which basically meant if you did all the instructions in the exact opposite you would probably be probably be a pretty good thief So that was commissioned to explore all the fraud patterns the anti fraud programs for mobile money And things again, but its focus was really only on mobile money and only on certain types of things Uh, but it was a very good starting point a very good guide. We still use the book regularly Um, next a group that was originally run by Deloitte Did studies on fraud typologies that affected central switches Now keep in mind that mojo loop is designed to be a centralized switch or a switch that runs at the government level However, I've been proving in my company that we can do it easy for a lot more things We're doing it with pan african banks and a variety of others and getting some some good benefit out of that So this was originally started by Deloitte And some of us started helping to expand on those typologies And then eventually it became a full fledged project about 18 19 months ago. So why do we start now? I love this phrase It's from urgen stock who's the Interpol secretary general With more than 4.5 billion people online more than half of humanity is at risk of falling victim to cyber crime at any time Requiring a unified and strong response That's why we're doing this now and that's why we're speeding things up And that's why we're hopefully building a very good engine that other people can utilize and can leverage and can Do any of the work with his own So it was code named accio. Um, we gave that that name latin for action Um, but it's really not going to be the name. We haven't decided that there'll be a whole focus Session and an organization that will deal with that process as far as the legality of it Um, but for right now, we still call it accio Um, that will not be the name at some point in time. So It's a newly developed open source transactional monitoring system And the key is progress management system I was talking about that just a minute ago and now i'm talking about a transaction monitoring system All right, so a transactional monitoring system is part of An overall risk mitigation program or service system Um, we're calling it the the whole system that we're trying to do a fraud risk management system But this is specifically talking to transactional monitoring what we can do with it So the goal behind here is to Reduce fraud money laundering the financing of terrorism and the greater financial ecosystem To reduce the cost of fighting all those issues because an awful lot of expense that goes into that Provide systems for those organizations that it could not otherwise afford it ideal I'm on the African continent and ideal on a feels like a daily basis with people that Only are taking their fraud efforts or the anti-fraud efforts to a certain level simply because they just don't have the budget So it's a choice operate or not operate So they have to make that hard decision of yes, we'd love to crank up what we can do We'd love to do that at a higher level. We just can't So hopefully these types of programs will give those legs Back to them and they'll be able to to do to take some action and do some things um, we'll be uh increasing financial inclusion by Reducing the pass through costs of customers due to fraud and fraud mitigation So there is an enormous amount of cost that gets passed through in the fraud programs There's always going to be loss. We can't get rid of loss What we can do is reduce it to an acceptable level So you've got to pass through the cost of the loss You've got to pass through the cost of the system You've got to pass through the cost of all the people running them and everything else And it gets really expensive and then depending on what country you're in or what jurisdiction you're in depending on if they determine if it's fraud or not That fraud might be passed on and the organization itself may be forced to eat that cost In which case it goes back into the system as more cost So there's a lot a lot of stuff that goes on place So so who's this for it's for financial service providers obviously system integrators So people that want to build services around this it's for regulators So a regulator in a small country like same allowing Could put a product like this on a list That could be available to a small insurance company or a small fintech That says hey, I want to be running Something for my anti fraud program, but I just can't afford it. I don't know where to go Hey, check out this. There's a lower cost barrier entry to entry and doing this Let's start here. So that's how the regulators can be involved But on the ISB side One of the things that I'm excited about is the way that we designed this engine Is so that it can be plugged into different points and it can be extended to different points So right now we're focused mainly on payments But we take out what's called the ppa the payment adapter at the front end or or what reads the actions or the activities Replace that with something for insurance and now we've got an insurance system Right now we're not a lot. We don't do a lot with machine learning Mainly because the regulators aren't sure about it It's a black box kind of a solution Yes, you can see what you put into it to run, but you don't necessarily know how I've made the decision So what we've allowed is a path In here so that you could run machine machine learning and then back that up with with an algorithmic type approach or things like that So so An ISB could get really created with this because of the fact that it's an engine So what if you want to make something that was focused on the the fraud around? Identity identity theft or identity fraud. Yeah, synthetic Identities And and part of that process was figuring out You know all all these things were we're coming up and we're coming from IP addresses in the wrong locations and things like that That is that's something that we normally try to To to pull into the picture, right? But if if you have an engine that is reading directly from the cyber tools The cyber tool kit and combining that with the fraud tool kit You're going to have something very powerful So I do think there's a lot of a lot of room to innovate and get creative here So, you know, what are we trying to do in general? We're trying to save the money with open source software We want to tune this and calibrate it. So it's just to your needs Just what you need just what you need to solve that situation so that you don't you know Spend hundreds of thousands of dollars on on a system that you're going to only use 20 percent Um, so basically implement exactly what you need again low cost to acquire low cost implement low cost That's we all know the mantra here and and what we're trying to do is far away. So software So what is this? Um Well, first off Let's talk about the fact that we went with a model called semi attached part of that Deloitte research was On researching models for operation and again, this was focused primarily on On centralized switches So what we wound up choosing what um, because it was more ubiquitous it worked for more More situations for more people is a semi attached model And that is where there's a centralized financial prime risk Every all the payments are going through a hub But all the digital financial service providers or dfs p's Are running a piece of the action on their own because frankly, they're always responsible for Whether they're putting good or bad transactions up into the system Um, so this is called the semi attached model as the model that we follow at the moment The portions in green are the portions that were built out for the mbp One thing I'd like to point out is this is kind of a part of a three-legged stool So you've got your kyc screening and your due diligence that goes up front We leverage that data heavily You've got your nightly screening changes that happen overnight We leverage that as well. We are the transaction moderates. So we're we're The payment transaction We're the transaction to change your value within a system the sub rights or for somebody to access something Uh, a password things like that We're we're that behind the scenes that's that's crawling through the locks and saying that users shouldn't have done this on behalf of that other customer for example So this information could come from from all over the close But the bottom line is is what you've got and you've got customers these institutions the individuals The financial service providers that are servicing them. You've got them And then you've got a switching hub that switching hub in this model is really meant as a central hub or a central environment But it could be any type of switch. It could be Efts a ch etc Um and in that monitoring then we've got basically the monitoring API service that monitors what's going on Data preparation the data preparation is huge and that the data preparation It's all about the data and and being able to make a good decision data preparation is everything from cast forecast pulls forward Pretty aggregate. It's just a lot of different things um Then there's the actual transaction evaluation and then it spits out basically for The transaction and for a typology So you could have multiple typologies that fire per transaction for one or none And then it sends that information into a JSON file which is packaged up So all the information could go into a case management system of each one step to be open source product could be whatever you want Um Could it could be sales force for that path at that point then you would go into analytics investigation mode And you're working back to forth with the body aids. So that's kind of how it fits into the the whole system So Let's talk through this scenario We've got a typology background a typology is just that it's just a An ordered structure of how certain things work together Um, so we've got a damu. I'm doing electronic funds transfer fund mobile money going through the payment switch We've got bingo on doing in the ft through the bank We've got chedgy doing a cash deposit through a money remember and so i'm going into that central hub All right The transaction amounts are very similar for each transaction And they're all catching out to two different people. So um, you can see that Within an organization and put together that picture and that becomes Um, a scam. So this is a typology 28. It's overall generalized a scam typology false promotions fish and social engineering things like that Um, but when you have a switch involved you can actually see what's going on more because you've got multiple banks or multiple financial institutions Sending the information upstream So you can see you know, they are getting you know lots of payments for these two people But they're coming from these three people at these bank this bank and these three people at the other bank So that is that's a huge thing. Uh, it's not Done a lot a lot. You know switches are opaque as far as information. That's something that we're trying to change So to continue on with the you know, what is a false promotion? fishing social engineering Let's do the rules breakdown so The the there's all information about the debtor did the debtor make a very large payment Did the debtor make a larger payment than usual? Is the debtor in a vulnerable age category? So someone over say 65 or something like that did the debtor's account activity increase compared to their history? Is this the first time the debtor is paying this particular creditor this particular person? Did the debtor pay the same creditor more than once? So we're looking for repetition or or evolving stuff Um, so this goes to the the transaction Monitor everything goes through there. The topology is evaluated on the creditor's side. We're looking at things Did the creditor receive a large number of similar transactions? Does the creditor receive payments from a large number of different debtors? Was the creditor's account dormant for an extended period of time? In other words, did it go dormant and just came up blind just for this one situation? Do amounts flowing into the creditor's account appear artificially random? All right, something's called Benford's law Does the creditor's outgoing transaction amounts match the sum of incoming amounts? Did the creditor's account activity increase compared to their history, etc, etc I'm not going to waste a lot more time with that, but that's basically a typology that is made of these individual rules So all these individual rules may be used by one or more typologies And in fact, that's exactly what we've got here So one of the things that we were able to do is we created a concept that we call the network map And and it takes to look at the type of transaction and it says For example, if this is not a forex transaction, it's never going to run a forex typology So why run anything for a forex typology? All right, so simple things, you know ruling different things out But then it also takes a look and it says all these right here Require this particular rule. This is Benford's law Do amounts flowing into the creditor's account appear artificially random? All right So basically what that means is that map will tell us that for that particular transaction We need to run that rule once and only once and then that will benefit all these different other typologies And that's some one of the many many ways we get additional tuning and we get additional performance out of the system Okay, so let's move on to typology modeling Uh, there is a lot that goes into this. We're not sure how to share this information yet On the enlist to say if we make it too public the bad guys have Get a hold of it. The bad guys are probably going to get a hold of it anyway So there's lots of conflicting opinions on how to deal with this But for the most part we'll we'll probably it'll be a select group that has to pass some some sort of background check to get access to the typologies There will be a group that continues You know working on typologies and updating them understanding how to use them And then normally when you you're putting something like this in place You would hire someone like like a Deloitte for example And they would go and they say hey you have this type of data Therefore you can determine these type of things and these amount of time frames And then we'd apply the typologies to and all the different rules and stuff like that But there's a lot of information that goes into these different typologies So what is the process flow? This is where I think it's interesting So I mentioned that PPA adapter Um, basically we receive um, you know from the client platform transaction message in this case All this is it's centered around ISO 222 This could be any type of format any type of message That's irrelevant. So it all kicks off with this PPA adapter the what monitoring system There's the apis that are for the transaction monitoring system that understand what's going on And now the message is for data preparation and things like that There's the whole data prep layer that has to go on data prep is continuously going on. We have a series of things that do That data governance And then as well as tracking all the journey and all the manipulation all the adjustments to the data Where the source of it isn't things like that Um, we have the crystal layer which is basically figures out what's the channel route, right? The channel is another concept that's used for tuning We have this concept called multiple channels If you have real-time rules for example that have to run very fast normally people would think of credit card rules Um, we would run those in a separate chain So part of that Transaction analysis would be do I need a real-time check? Do I need a real-time addiction? I guess I do it's only three these three rules These three rules will run in that channel and then later on after that channel's been processed The other rules will catch up and things along those lines We have all the individual rules. They're all again working off of an iso 222 compliant model Um, we then have the aggregator for the transaction And the channel aggregator that goes on so Um, basically we evaluated topology level did the topology have enough stuff to fire Um, what if we ran five technologies for a given circumstance, but none of the five hit their limit But two of them when combined did actually hit their line So we're evaluating through things like that and then we're evaluating at the channel level as well And then we're doing we're again, we're aggregating at the at the actual transaction So did anything fire for the transaction? And then at that point we we export we basically create a series of files that are used for two things Although we say cms the reality is it's if you have a system where we have to send an alert someplace else And then the cms system That would work most ways we see stuff is with cms Which will then fire off failers and stuff like that and start the investigation process Um, all of this basically means that once we get to the channel processor router set up There's a lot of things going in flight and we've got the ability to auto scale scale up and scale down Um to to manage all these different things So, um And the the topology lifecycle is is interesting Basically, you need to develop the individual rules You need to sit back and compose the individual typology um, so one in those rules, um You know go together and how do they go together to make up that typology and deploy the typology Then you have to calibrate the typology So we mentioned age earlier ages in early one for a determination of both age of account Um a scenario like that an account hasn't been has been dormant for 90 days. It suddenly it's activated Maybe you should take a look at that Or if a certain type of a scam Some it's a scam portfolio is suddenly working for someone that's like sale of the age of 65 or 70 But that would need to be calibrated for your particular environment. You could have a younger set of users You could have an older set of users Um, all those calibrations need to occur and that's part of this entire process So the first is we we we build and define the rule Then we compose this into topologies. We deploy those typologies and then Excuse me for the given circumstance For um for a user we would calibrate that for their environment and for their needs And in this case, uh typology 28, which is we abbreviated and call it scams Um has all those rules rule three eight 10 11 16 18 and so on And then everything after the at simple is the version level. Okay From a data model standpoint, we have a robust data model. We Take advantage of a multimodal database. So we do have a graph database and we have a doctrine database In the system. I'm not going to go into too much detail about that Nevertheless, it all works well together and we use an i-fi as far as feeding the system and getting things into and out of the system doing manipulations on auto system things like that Excuse me And I'll just move on with those items So in the stuff that you're probably more interested in talking about is these What is the actual architecture? Um Again our remit and I think I missed that slide here somewhere, but there was supposed to be a remit as far as what it is that we were doing And what I mean by that is is we had a target of being able to process 3000 transactions a second And we had a a target of being able to process a single individual typology within 35 seconds So if there needed to be a real-time stoppage of something In the case of a real-time interdiction that could be done within 35 seconds Now what we've done with all this is beginning a project We actually timed everything out and improved That we could meet make those speeds. In fact, we we tripled the speeds That once we could prove and we went into how do we create a simple to a simple solution That solves a not very simple problem That can be managed pretty well um So basically from there, we we adjusted the parts the pieces and parts as far as what we were using um You know ambassador for examples are a ki gateway whereas we sit within services mesh that link or d so all the security folds up The actio individual services that create those channels that run as those individual tunable channels Run an open fast, which also scales up and scales down Actually vault actually corporate evolved key club, etc We do use caching. We use red as caching and rango db for the persistent data store The elk stack as far as the apm the dashboards and the reports We do have complete telemetry on this entire solution um As I mentioned nifi is is in use for we use it both for the pseudo anonymization in the layer because we're We're trying to take that risk out of things We're doing it for the entity resolution and a lot of the data transformation the persistence the whole model how it runs through the entire system and then The whole thing runs in a kubernetes stack um And we uh, the cscd is basically run by genkins testing and postman and there's another testing Uh objects that are are nemen only Um, that is about what I've got for you. Um What I am going to go into is this is kind of the end of the presentation um This was kind of interesting because we weren't trying to give you a lot of tech and we weren't trying to you know You have to show you enough tech. Um, we were trying to show you the problem. We were solving So this is the actual slide one of the the early slides they went with modulate which said, you know building an ecosystem that benefits everybody Um, I've taken that and I've added an antifraud ecosystem that benefits everybody still benefits fintech central banks governments versions users um We're in the process of building over the course the next year the open source fraud risk management system center of excellence Um Have no idea what that's going to be called yet. It's going to be an interesting journey as we go through the year And we'll see So thank you very much. Um join us. There's plenty of room to engage You we're looking for adopters. We're looking for people. Um That uh, that that want to be early in that maybe maybe have a Customized need even we're looking for that. We're looking for people that would contribute and we're looking for people that would join the foundation Or excuse me, it won't be a foundation to the center of excellence. So thank you very much. Again. My name is Greg McCormick I'm the modulate foundation technical along the governing board for the technical board and um at sarvin systems. I am the chief strategic business development officer Um, those are my my emails. Um, when it comes to this in particular if you're trying to reach out to me I would use my personal email first Um, we're trying to run this stuff kind of independently Uh, but cyber is a major part of the organization. It's a very powerful supporting sponsor. It's uh, Basically, they ran this project for the past 18 months. So thank you very much