Scale By The Bay 2018: David Massart, A Reactive Fraud Monitoring Engine for Instant Payments
young David Masada for a small consistency company and we are helping but our customers to scale things up or all kind of ways and so what I'm gonna show you the architecture of a reactive fraud monitoring engine that we well will help again P by authorities to to put in place so sorry not sure why okay yes so basically when you want to transfer money as a initiator of a payment you're gonna interact with with a channel of your bank and could be a mobile app the bank website something and you're gonna always encode the the credit transfer and when the free transfer is ready well the data is going to be sent toward the transaction is going to be sent to a payment engine and this payment and gene will make sure that the money arrives with transfer from your bank account the bank account of the beneficiary and not very fine it's a relatively slow process and typically takes about one yes one one business day so as that's sorry about that yes and since money is involved you have always false or try to get some by just interfering either by well trying to convince you to to transfer money to their bank account or by trying to stealing your credentials and just when doing the transfer themself so that's really annoying yeah the way okay the way to to avoid that just trying to work use a well all the data provided by the feminine genes trying to transfer that were from monitoring system that's typically opting in batch and then you apply to this data machine learning rules and you try to generate alerts and when you okay and okay so once once that you have these alerts are monitored by well fraud investigators with real people just going to investigate the case check if it's really fraud or not and you can't really stop the payment so and this this works relatively well because you have time basically you have your one business day to do that and so most most of the fraud are code by and stopped by by this time of of approach and and unfortunately this year the legislation in Europe has changed and a lot of systems new things have been put in place one of it one of them is just that no you have what they call instant payment meaning that no banks have five seconds system instead of one business day to transfer the money from one bank account to the other so that's one thing to make things worse well we also start open banking so various well banks have to provide api's to a third parties so that anyone can basically provide services develop apps and get access to these api's to to offer services to the bank customer and all that happens in the context of the GDP our value have new restrictions on the way you can use the data and so that's usually trying to limit fraud this relatively legitimate and so will you okay you get actually keep getting access to the data okay so okay yes so basically you see I mean it's relatively simple you it said if you reduce your own place you play manage in your slow payment and gene by an instant payment and gene there's no way you can keep sorry you can keep stopping fraud and by the time you the system is in place it's too late and we had to come up with with a new system so what we call a fraud monitoring engine so the idea is ready to okay really okay so really the idea is new is to interact directly with the channels each time and there's an event at the level of the channel you try to receive it you as fast as you can and at some point you return or some some instructions for the for the channel and so that channel based on your instruction can decide to send the sender trade transfer to the payment engine or not so there is no not trying to well once you reach nearly instant payment engines things are too late six-hour process you don't interfere with these five minutes limits that you have you just try to do things before that and if you and so if you if you look at this it's really a typical reactive system that you have to put in place because you have to okay okay yeah because basically you need to react to be fast you need to provide instructions within 350 milliseconds possibly less after you've received the last event or you have to update actually these instructions each time you receive a new event of course you need the system to be able to scale to scale up and down to accommodate the variation and if you have peaks of transfer also typically there are at at BNP at the moment 1.2 million transactions per day with well moments that are quieter than than others and we are picked up two to five hundred transactions per second which means of course for each transaction a lot of lot of events and the system with instant payment you need to be available 24/7 so what boost her business is important to so we've tried to come up with an architecture like this where we try to paralyze things as much as possible so when a channel contact the fraud monitoring engine events are sent to the dispatcher that will just distribute the data depending on the type of data two different protective modules and so this mainly machine learning models that are while using in parallel so we want to reduce the latency as possible so we really have to well fire all the models in parallel and collect the different output to an instructor that will just aggregate the DS output and based on some fraud policy interpret it and provide the instructions okay so basically what does the dispatcher do it's gonna split advanced into into various data facets and publish each of these data facets to while we use Kafka so we have a dedicated calf cattle pigs and then these calf Catholics receive different each topic received a different type of data and the different predictive modules that consume these data are going to subscribe to to the topic the each of them focus on an aspect of interest so a part of the transaction and the reason to do that is that we try to at this stage maximize a recall so at the moment we don't want well which we don't at this stage we don't really worry too much about false positives we we let each module focus on on an aspect of interest and try to yes to maximize the record try to catch all the things that look suspicious and the results is a partial score that is sent then to to the instructor and all the partial scars are interpret it at the level of the instructor well we have a second phase with also machine learning models and and rules and the idea is to aggregate all the partial scores into a consolidates car interpret discourse attorney into into an instruction and the instructions are typically well go the payment is fine it can be processed stop the payment or that's when it there is a clear cut or in a lot of cases basically a step up so try to have a some kind of extra complication depending on what suspicious asked the channel to interact further with with the the customer to make sure if that's really the customer and it's really what what they want me to and at that stage there we we try to maximize the precision and to eliminate the false positives so if so if I look at the implementation so as a backbone for exchanging messages we rely heavily on Apache Kafka for then everywhere when it was possible we try to use fleeing soldiers ready to dispatcher for predictive modules that are JVM compatible for the instructor unfortunately well even the context we had all these models that were already used on the on the former platform and all they were developed in mostly in Python and our by the data scientist and since we had new youth fraud since it was not possible to convert all of these models into something that can be used and deployed on fleek so as a yeah the temporary solution we basically these models were darker rised and and deployer that way okay so if you look return the idea so just an example with two type of facets you have different models that are reading from the facet producing the scores seeing is that also the dispatcher I to dispatcher level that something I haven't mentioned yet but we've also added some some white listing so the idea is really that when you look at different transactions so much you don't have to score all of them I mean if you're transferring money from your saving account or from your current account to your saving accounts okay there is no reason to think that that is fraudulent off if you pay the same amount to the water company every month okay that's all so this kind of transfer can be can be trusted so in this case we have some kind of white list of some transfer that where you can provide a score immediately and send it directly to to the instructor with an shortcut the different predictive modules and these this transfers are relatively important I mean in the volume of it is relatively important so it's depending between 60 and 70% of the transactions that you don't have to to score in detail okay then yeah just another advantage of this type of architecture is that okay you have to retrain regularly your models you have also to go you to generate you one's and so one of the things we put in place a way to basically try to validate to a staging area where you validate your Madhu's your new predictive modules before you put them in in projections the idea is that all the data at each stages are collected into a data lake so that we can we have-well all these historic data of all the previous fraud and non fraud cases and that can be replayed so we can compare the result the that was obtained in the past by the previous version of the module on the historic data and compare it to basically the same data that are applied to the new to the new version of the module and you can also actually compare performance of the new model to the one to the production model by just well getting that the real-time data from the production environment and then comparing actually the performance of your production model to the performance of the new model and when you're confident that the performance is of the new predict module are better than the old one you can you can deploy it okay so just looking at that so basically the architecture that I just presented works I mean it works well I'm in terms of performance ease I mean we have reached our objectives or the system works the way we want however I mean everything is not as well the management is a P but it's not as as good at it cool so one of the reasons for example that we don't one of the goal was to have an elastic system that really scale up and down and with this kind of approach I mean that's not really the case you have to imagine the worst case scenario where the highest rope route and provision all the infrastructure from before for these things and so you accommodate everything but you don't really have the possibility to scale down when when things are going well our mark on the other things that the approach is of Decker izing these non JVM models I mean each word but it's it's a DevOps nightmare really so it makes everything more complicated it's I mean deployments are more difficult you have a lot of other things to monitor to to to to manage and yes so that's causing troubles really so one of the things we are trying to do while we plan to do in the in the future is possibly to gain more elasticity try to to move from for example Kafka to prevail yeah that is the possibility to actually dynamically allowing the NAM changing the number of partitions depending on the load on the queue and try to see it well turd that's one of the things we would like to do the other things really that we would like to get rid of docker as fast as possible and so we're working with the data scientists on basically getting new versions of all the various models so that we can move all the old infrastructure on free and that's basically the things I wanted to to share with you today thank you [Applause]