Alogent Webinar: Payment Solutions and the Benefits of Real-Time Image and Data Validations

Hello, and thank you for joining us today. I'm Wendy Klein, VP of marketing here at Allergen, and today's webinar will feature Unify, our single deposits platform for full and self-service channels and how you can leverage real time image and data validations to streamline your user experience and fight fraud. If you have any questions, please type them in the chat box and go to webinar. We'll do q and a at the end. And now without further delay, I will pass it off to Ashish Bhatia. Ashish? Thank you, Wendy, and thank you everyone for taking some something time out of your day to attend this, webinar that we are doing today. Think about thing basically, like, a real time that they're within data validations thing as well as key image validations that we can can do thing as part of this solution. Kevin, the given given getting the dynamic in nature in which, fraudsters are I think trying to, in trying to create fraudulent items and pass them off within the system. I mean, not a day goes by these days. Wake up. This is not happening. And especially, I think, during the pandemic, from from the time of the pandemic, it's really exploded because that's the time that people had a lot of time on their hands, apparently, to go through and try and find out how they can how they can game the system. Hunting checks, unfortunately, were, were the main target hunting continued, continue to, be so. And what we wanna show you today I think I know in the past we've really spoken about, what Thing UNIFY is. Yeah. Today, we really want to show you things that we've get done as part of the solution and things that are coming up, which we are really excited about to bring to the market that, financial institutions can think leverage to really look at get data all in one place rather than having to look at, multiple systems or the multiple screens to try and make a decision haunting one item. K? Because some some of the financial institutions that we have, visited as part of our care discovery are using multiple care systems, which all all financial institutions do because there's not one solution out there that gives you all thing that you are looking for in terms of data as well as image validations, as well as making sure whether the item is a good item or not. People can visit and have visited Wikipedia and have found out, for example, how how the check how how the routing number is, is, is created by the Fed. Right? The first four digits being being the FRB, the chemical for the ABA, and then you calculate the check digit validation. People have gone on to the Internet and have found out and are creating checks. So while they may pass check digit validation and it make it look like a invalid check, more often than not, on day two or three, it gets get returned. Now you can certainly can look at some of getting the other systems. You can log on to them and, try and validate it. But those are the things that we are trying to streamline and really can bring together so that when we are going through or someone in the back office logs in or for that matter, a teller, when they're looking at the item as they're scanning them, through the teller capture, they can really can look at all of the all of the data that's get they get associated with the item from the multiple ecosystems in place, within the financial institution to make a meaningful meaningful decision on the item. So that's what, we think targeted targeted UNIFI for. And I'm sure if, you've participated in some of our webinars previously. You've heard us say that on thing more than one occasion. But, really, today, what we wanna do is take you through some of the things that we have, brought on. Well, our thing with CareUnify that you can take advantage of and also show you what is coming, hinting subsequent care releases, within the system. And with that, I'll turn it over to my, to my colleague, Alfred, to take you through the demo. Alfred? Thank you, Ashish. Let me share my screen here. Okay. You should be seeing a screen with back on during a check image. Just wanna confirm that that's what you're seeing right now. Yes. I'll just Okay. Good. Alright. So we know that, you know, fraudsters, they they they they they take on many tactics, and they wear many hats, right, in order to get a leg up on the FI or the account holder. So within the UNFI platform, there are a couple of things that that we do to to help to, to keep abreast of the changes, in the fraud landscape. Not just keeping our ears to the ground, but also to talk through what, you know, functionalities that we need to have and features we need to add in the product to help to mitigate fraud as much as we can. One of the things that, and I'm displaying the screen here. And this is showing that that during the capture process, there are profiles and and other things and web services that we can call out to to validate the the no negotiability of an item. Right? So we talk about image, validation. We do check the image for certain things like it meets the Fed specs. And at the end of the day, the image can be, you know, sent to the Fed and be cleared appropriately, through that process. The other thing that we do is that we can call out to web services that as it's shown on the screen, we can call out to our service to return information about the item, if it is flagged for any, you know, any, you know, the code line or any other information is flagged as a suspect. And in this case, the user can, you know, as as Ashish mentioned, everything is in one place. You see the image on the screen is showing the information related to the fraud suspect, what's being returned from the API call or from the web service call. And then within that same screen, the user can make decision on the item whether to accept it, because, you know, for whatever reason. Right? But to take, you know, immediate action to be able to accept the item but place a hold on it or to deny the item, which means I do not want to accept this item. So everything is there, you know, for the user to make that decision, you know, within that same session and as the check is being captured, to be added to the system. So there's there's a couple other, there there are a couple other use cases, right, as part of fraud. Because as we know, fraud takes on fraud could is a lot of things. Right? It's anything that, you know, allows someone to gain an, you know, unfair advantage in terms of taking advantage of the of the system. Right? So some use cases could be someone is trying to pass a check twice. You know, they're trying to deposit check twice. They're in the they drive up to a branch location. They're at home, make a deposit to their mobile account, you know, through mobile deposit, and then they take that check to to a branch location to try to deposit that same item. Right? Within Unifile, we do have duplicate detection across channels. So if they did it in mobile first, then went to the branch and tried to do it in teller, at a point at which they tried to make that deposit in the, you know, in the telechannel, then that item will be flagged as a duplicate, and then the teller would be able to to, to see the the the the the item that was first deposited through the mobile channel and be able to not accept that check. Right? So that's one way that, one use case where we are we are doing this, validation and, you know, allowing the teller or the FI to take corrective action at that point in time. Other things like, you know, account takeover. Someone takes over someone somebody else's account or fraudster takes over someone's account, and they're trying to, you know, gain act you know, they gain access and, obviously, they're trying to make small dollar transactions. Right? So as part of our our archive solution, which is Aware, we have a model where every single transaction is written to that database. And, you know, the key is the RT and the account number. So on those items, deposits can be modeled or can be, aggregated to be able to do this type of, analysis. So if an item is presented for payment that is outside of the range of what the normal, amount is for for for that particular key or that particular customer, then we can flag that. Right? I like this to, you know, like your credit you're using your credit card. It's outside of the rate the the amount that you're charging is more than what you normally charge, or you're in a location that that's different from where you normally conduct business or normally use your credit card. You get a call or you get a text to say, hey. We stopped this transaction because we need you to verify that it's you. It's it's similar to what the to what the aware, score model or the fraud model is is meant to do, is to be able to detect anomalies or differences or changes in the behavior and the activity of the account, both on the check side, the check resentment side, as well as on the, deposit side and be able to say, you know, flag those items for review at the FI so you can take corrective action and and review the item or review the transaction and take corrective corrective measures. And like I said, it's it's not just, you know, we're looking for large dollar amounts. It could be a case, you know, going back to the account takeover. If you're trying to test the account, so to speak, then you would what we have seen is that the fraudsters will make smaller transactions, smaller but frequent transactions just to do this test. And those you know, thinking that those will fly under the radar. And and that's why we're flagging these as well. Right? We're checking for the activity, the the count. You know, you're making this customer is used to making two deposits per month. Now I'm seeing, you know, five deposits, you know, within a day, with or within a twenty four hour period. We're able to use that as a profiling method to flag that transaction to be reviewed. So, you know, the again, mitigating the fraud, on that account. And also number of checks drawn. I'm used to, you know, on my check on my account, it's normally five checks that is drawn on my account each month. You know? All of a sudden, I'm seeing, you know, twenty checks drawn or ten or whatever the case may be. We can, you know, add those filters where we can flag those activities and, you know, flag those transactions for review by the FI, or depending on how stringent the FI wants to be, you know, to reject those transactions outright. So there are a lot of, possibilities there in terms of how the the financial institution wants to, address those those conditions or those use cases, when they do arise as part of the system. So that's the, you know, in during the capture, not just validating the image, but also validating that the check is is fit for is negotiable. Right? It can be passed through the the system, or passed through the payment system with no problems and it's collectible. Another thing that that we we have as part of the UNIFY, offering is to be able to do payment invalidation. So in this case, Emily, the check is payable to Emily. As part of the payment name validation, what we do is check against we get we receive, a file from the FI, could be a CIF, with the account holder's name in the case of Emily Emily. And we will look up against that account, use that account number to look up against the the CIF, and verify that Emily is actually the account holder or is one of the account holders, whatever the case may be. And, that's part of what we do. It has, you know, third party dependency because it would require, like, a recognition engine to be able to read the name of the check and return the information. But that's another plus that's another process that we do here to validate, you know, the the the deposits. There's also positive account number lookup. A check is is is, is presented for payment. We can validate upfront the account number on the on the on the item, some honest item. And, you know, again, looking up against the same CIF to validate that the account number is actually one that is, that's a good account number at DFI. There's also a positive pay. And as Ashish mentioned, things that we're adding to the offering as well, where a merchant a large merchant may write a lot of checks or a customer may write a lot of checks, and they will present a file with all the checks that they've written, the amount, the payee, the check number. And as these checks are presented for payment, we will look up against this this this this file to validate that not only that the payee is is correct, but also that the amount and the check number matches exactly to what they to what they, to what they, to the checks that they wrote. So that's that's those are some of the things that that that we're adding. And then Ashish mentioned, the RTE validation. So, you know, last year mentioned, right, someone can go on Google or go online and figure out how to how to do a mod ten routine. Right? A mod ten check digit validation. So we also have third party third parties that we're working with to validate the RTs. So if someone wants to create a check, you know, see somebody's account, create a check, and put an invalid RT there, for example, we're able to make a call to this web service and, you know, to validate the actual RT. So none of the RTs that somebody may write or use their skills to create that would pass them the the regular check digit routine, you know, those will be caught and will be flagged accordingly upfront as the check is presented for payment. Another thing that I want to show you as part of this is we do have a model a modeling, a model that that we display, to the FI that helps you to see how well the fraud, the fraud filters are working for you. Sorry. Just take that. Log in here. And what is that, it it gives you an idea as to how well the the process is working for your financial institution. And you can also see, the information related to that. And this is this is part of what we do in Aware. It's it's more for long term a longer term display of information and and, you know, the checks that you've captured over over a certain period of time. And it kinda gives you an idea as to how well the you know, how well we are catching, some of these, fraud use cases. You know? What's my what's what's my success rate in catching these and being able to to to display to you based on the data that you've collected, how effective each of these fraud filters are. Let me get to this to show this information here. Okay. Let me alright. So we have some some of the projects that are such as we have some other things like high deposit high deposit activity modeling. And it shows you within that time how many have been how many failed for a given threshold and, you know, how many were tested, as well as high number of customer score failures. So we also as part of the fraud process, and as part of this this this feature, we assign for the for each account number and RT combination, which we call a key, which is unique per customer, we, we calculate a value, a number. And that number can also be used for other things related to, you know, if you're making a deposit and, you know, there's a certain limit that you are subject to, and they want to do you wanna do the FI wants to do an automatic, automatic approval on that deposit, so reduces the number of reviews that you need to do. We have that we use that value, which is called a customer score number, to augment that process and help you to to streamline some of your process within the within your operations. This also gives you a a a view or a dashboard view of how well each of the profiles or or how effective each of the profiles are. Like, item item amount above threshold, we we monitor that based on the data that we've collected. High deposit amount modeling, that's the other other thing that we try to, you know as we collect the information, we show where the concentration of the of of failures or or success are in in in terms of giving you over time, you know, what is what is my success rate or failure rate for each of these, for each of the profiles that are displayed here. And the profiles, by the way, can be, can be configured to whatever the FI deems as most, critical to the operation. You know? Low tech number one Alfred. Yes. I think, Alfred, if I'm, may so if I may, take a minute out here. I think I think we also need to talk about how we are going to take the data that's here and think to display it, I think, as part of so as part of getting the so as part of of the process of review. So how will this get data be presented over there? Can just take a a minute to walk us through that as well? I think so that it's yeah. One screen where people are looking at it while we can we've can build this data model. How is it gonna be relevant thing in the care review process? Right? I think, we should, build that up as well. Sure. As I you know, as I show this this screen, this one is showing for a fraud suspect because, basically, it was configured for that. But if it was configured for the for the internal fraud model, then that information will be displayed here as well in text. Right? And showing you for this for this check, we have you know, it's above the average or it's below the average, but the count this, you know, this item exceeded the count. So we'll be able to show this information at the bottom left, this the section where I've shaded. This information will be displayed here to help the user to make that decision as the item is being is captured. Right. So they won't have to, go to, go to, I think, a different screen to get that information and then come back here. Right? So that That's correct. Yeah. Yeah. Yeah. So I just wanted to cap make sure we clarify that. Thank you. Thank you, Alfred. Sure. Sure. Yeah. That that fraud modeling screen was just to show, like, if there's someone at DFI who wanted to take a look to see how effective each of the profiles we're doing we're doing or if they need to make changes to it, maybe change the threshold, then that would show them, you know, hey. I need to make changes in my configuration to make sure that I'm catching, you know, some of these issues. But once it's once the item is captured, everything would be displayed in one screen here to show the the details around why it was flagged for review. Yeah. Perfect. And I think we are running up against time, and I know, Wendy, think that you, mentioned that there are some, questions that have already come, thing in the thing in the chat session. So if we can take them since we are running up against your time here. Don't mind. Right. Or was there anything, Alfred, that you just wanted to say in terms of getting a wrap up thing before The main thing I mean, the only thing I wanna add is that I mean, in this case, we're showing back counter, but it would be applicable to any point of any channel, whether it's, you know, in clearing files, any other all channels where we are ingesting these items and and and committing them to the database, they would be they would be subject to be able to run against all these fraud models to provide to to detect and also present for review. Alright. Thank you, Alfred. Sure. You're welcome. K. Perfect. Thank you both. We do have a few questions in the queue. If there are any additional ones, please, put them in the chat. Our first question asks, if using Unify for RDC and another vendor for branch capture, will Unify still detect duplicates in real time, or would branch capture need to also be Alligent and Unify? Yeah. Thanks, Wendy. That's a that's a great question. So we can only get detect duplicates with the data that is within within our ecosystem. Right? So if, let's say, a check was captured through branch capture sorry, was captured yes. Let's just go with that through branch capture on Canada's system and also scan through commercial commercial desktop, the only way we can then detect it if commercial desktop is thing is running on CareUnify is if we have that data within CareUnify. So in terms of career time, if I would think about this scenario that, with this question is talking about is that someone through commercial commercial desktop through k Unify captured the item and let it go through, and then it was and and then brought it to the to a branch where it's captured through a back counter through another calendar, it won't it could be captured. I'm sorry. It could be detected as a duplicate in real time in back counter if that back counter solution can call out our thing duplicate detection web service. I think if not, then once once the item is comes in through comes in through comes in through K Unify, if we are the system of the record for clearing and creating cash letters, then we could catch it. But but it wouldn't be a real time. For it to be to our truly a real time, it would be, and if we talk through the same scenario again, is that the item is captured through commercial desktop and someone walks into the cab branch, and they capture it through cab back counter, which is running on Konka Unify, then yes. When they are capturing it, it will be flagged as a duplicate right away. Yeah, Wendy. Anything else? Any other questions? We do. Yeah. Okay. So the next one asks, how long is data kept within Unify to detect a duplicate? For example, a check is deposited one year ago and redeposited today. Will Unify detect the duplicate in this scenario? Yeah. So we have we have, modeled, get duplicate detection, basically, on thing the length of the negotiability of the check, which means, that, usually get checks are valid for, k, one hundred and eighty days from the date that's written on the check. So just get given, from that perspective, we do get duplicate detection for one hundred and eighty days. But if the item was get deposited, let's say, one year later, we there's just things spitballing and sitting out here. We can certainly we can look at the date of the check to determine that it is getting a stale dated check and get rejected on those lines because by that time, it is really not a negotiable check, by the letter of the law, but it will not be caught through a duplicate detection. Great. Our next question asks, is Aware included with AFS or Unify, or is it a separate product purchase? Yeah. Great. So when we think typically bundle our, our back office solutions can unify as part of the offering. So when you buy so we have four different cab bundles for our back office. They're limited where the data is held for one hundred and eighty days. And the other three bundles all hold data for up to seven years, but there's differences in functionality in terms of whether you wanna process in clearing as well as get chargebacks and get returns. But, short answer is that we include GetUnify in all of the bundles, and you don't have to purchase it separately. Great. And, we are at time, but I wanna do this one, additional question. Mhmm. Does the accept or on hold create a savings hold within the core? Yeah. We can certainly work with, any core that the financial institution is working with. I think as long as we have a herthing mechanism to, send the information get related to the hold hold on a particular check to send the information onto the core. We have we have done it in various ways. We've, I mean, especially on I think especially on so on getting the deposit side, we when we create a posting file, when when we are not kept posting in real time thing, let's say, from thing from the Katella, we have certainly, we have done posting files where we have think with the information, get related to the hold on an item, get within the file, thing so that when the file hits the core, I think that's when the right hold and and all other pertinent information related to that, is, placed on hold within the core. Great. Thank you. Yeah. And thank you, Ashish and Alfred for, your time today and for everyone, your time for joining us. If there are any additional questions, please don't hesitate to reach out to your Allergan account team or to us directly through the website. We will get back to you very soon. Thank you again for joining us, and have a great rest of your day. Thank you.