What's up, fraud fighters? What if the reason your fraud program isn't working isn't your tools or your team, but the fact that you're calling three completely different things the same thing? Because right now across the industry, fraud controls, fraud strategy, and fraud processes are being used interchangeably, and they're not the same thing. And that confusion—that's where the gaps are, and fraudsters love gaps, right? So for today's episode, I'm bringing back someone who was a part of the very first Fraud Forward episode, Angela Diaz. And this conversation came directly from her, which I love, because when practitioners say, “we need to talk about this,” that usually means there's something real happening in the trenches. So Angela, welcome back to the show.
Thank you so much. I'm super excited to be here, and thank you for being open to the topic. I think it's really important in the industry, and just like we love to fill gaps in fraud, we like to fill gaps in the industry. So I hope the audience appreciates it and finds value. So thank you.
Absolutely. So on the surface, you know, this sounds simple—control, strategy, process. We all know what those mean, right? But in practice, they get blended together, misused, or worse, assumed to be happening when they're not. And what that leads to is something that I see all the time also, is teams that are busy but not effective, programs that have tools but no direction, alerts firing but nothing actually stopping loss. And so today, before we get into solutions, we're really going to slow this down, because if we don't define the foundation correctly, everything built on top of it is going to be off. So again, before we can fix anything, we need to get clear on what it is we're even talking about. Angela, I want to start here and really level set for everyone listening, because these terms get used all the time. I use them all the time. But they don't always mean the same things depending on who you ask. So how would you define fraud controls, strategy, and then processes?
So your strategies are your overarching plan. Your how, your why. Some examples of that might be making risk-based decisions, making cost-based decisions, making customer experience versus stopping fraud decisions. You're going to factor in your risk appetite. So it's your overarching plan, a lot of your whys, your decisions you're making, your goals and objectives. Your processes are a lot more simple. It is the tasks or the steps that you have to do that are repeatable in a certain order to get to an objective or a goal. It's what's going on every day in your operations environment. And your controls are specifically placed. They can be on top of your process, they can be built into your process, but their specific objective is mitigating risk. And that's the major differentiator between the process and the controls. Those two are often confused very easily. A good example of that as well is if Angela, every day, locks the door on her way out of the building because she is the last one out of the building. So she is supposed to lock the door. Often leaders will be like, well, that's a control. That's mitigating the risk of the door being left unlocked. No, that's your process. Your control would be if your process breaks. That could be Angela forgot to lock the door, right? That's the process step that could be missed. Maybe I remembered to lock the door, but the door lock was broken. But the control would be a sensor in the door that alerts if that door shows as not being locked a certain amount of minutes after Angela has left the building, right? That's the control that is on top of the process, built into the process. So I like to use examples because I think what catches people up a lot is when we design our processes, we do have an objective in mind, and something does need to happen. And we know that there's a risk of that thing not happening. So we often want to label the process step as the control and argue that that's managing the risk. But the control is supplemental to your process. It's there so that if your original process step does not execute the way you needed it to, or perform the way you needed it to, that risk is still mitigated. So.
I love that you explained that because as you were going through your example, I was thinking, okay, that's the control because the door is locked. But you're right. When it is a process that is manually being done by someone else, it can't be classified as that control. And controls aren't always automated, right?
Correct. And also, too, you just brought up a really good point where I want to also interject. People often assume that because something is systemic or automated, it's a control. So maybe there is an automated lock setting on that door, right? So take Angela out of the equation. Maybe that door is on an automated timer that at 11 o'clock every night, it automatically locks. Well, what happens if that technology breaks or there's a glitch? You still want that alert there that detects if the door is not locked by 11 p.m., whether it's because a human forgot, you're in a manual process, or automation or technology that you built in to lock the door at a certain time does not work. So conceptually, it really doesn't change. Automation is great because it often introduces efficiency. It often is more accurate than manual, which lowers the risk. But it still doesn't circumvent the need for a control.
And so I think I have a thought, but I'd love to get your insights on, where do you think the biggest misunderstanding between these three is today? Because again, I'm trying to think with your example that the strategy is like holistically, what are we trying to accomplish here? And we're trying to make sure that nobody gets into the building that isn't authorized. And then how we go about thinking about that. And we think about all the things that have to be considered into windows, locks, doors, you know, whatever. And then you have your controls that can be automated, but sometimes they're not. And then you have the processes that ensure that the controls are working and vice versa. The controls are making sure that the processes are working or kind of like they fall back on each other. Is that kind of what you see or am I even part of the problem with misunderstanding, you know, between these three?
No, I think you did a great job. I'm going to throw an additional wrench in there and mention performance monitoring too, because even the counter argument, and I love when people have counter arguments, could be, well, what happens if the control breaks or what happens if the control's not working? Like, where does it end? And that's a really fair question, right? And that's where that performance monitoring comes in. And we take that same approach with our strategies as well, right? When we put our strategies into place, we often have some type of performance monitoring because we want to do pulse checks. Are we meeting the goals and objectives that our strategy was intended to meet? Do we need to change them a bit? Course correct? Did something unexpected happen? So we're always performance monitoring our strategies, tweak and adjust, and then with our controls, same thing. You don't need to necessarily layer redundant process and then control, control, control, control because again that's like, where does it end? But you have to put in some type of higher-level overarching monitoring so that you know that your controls are working the way that you need them to. Is the door, you know, checking that either the technology and the coding is looking the way that it should look, like something that could show in a seven-day period? Did the, you know, did the door show as locked at the right time? There's all kinds of different monitoring activities that you put in that aren't redundant to your control. They're not done at the same frequency. They're far more efficient and high level, but that are considered more of that performance monitoring category. Thank
So if someone is using these, though, interchangeably, what would that signal to you about their program?
That they probably have gaps and that they're probably not in a position to manage their risk as effectively as they should. And they may even have redundancies, which sounds odd when we're so used to talking about gaps. But I do often see that there's also controls in the incorrect place and redundant controls. And that's where that performance monitoring is key as well. So you should be using your performance monitoring to not only understand where you might need more controls, but where you might have controls in the wrong place or where you have the opportunity to maybe be more efficient in where your controls are.
So you kind of answered my next question, but I just wanted to kind of reiterate it that this performance monitoring is probably one of the most underestimated things that should be used and at least considered as a part of your strategy that, you know, we've got to make sure that we are making sure that things are performing the way they're supposed to. We've got to set this up on a regular cadence and then making sure that we're looking back to, hey, is there
process efficiency that can be done based on what we're learning from these performance metrics and so on and so forth. So I just wanted to kind of call that out too.
Definitely, yeah, absolutely. And that was a great call out.
And so I think now we can move on. If you're not clear on the definitions, obviously it would make more sense and be no surprise that that's where things start to break. So I think this is where it gets really important. This isn't just a terminology issue, right? I mean, we can argue, debate, whatever, back and forth on what word means what thing. But what we're really talking about is this is where the loss happens. This is where operational breakdowns happen. This is where teams start feeling like we're doing everything we're supposed to do. So why is this still getting through? But what I see over and over again, and what you've kind of helped spur the thought process for me, is this: we have a strategy, so we assume we have controls. We have alerts, so we assume we have coverage. And then we have a process, so we assume it's working. And those assumptions, that's where fraud wins. And Angela, you've been or you've seen this across different environments, you know, different institutions, different levels of maturity. So I want to get into what this actually looks like in the real world. So my first question is, where do you see institutions get this wrong most often?
Controls versus processes, 100%, especially in the fraud world because strategy is such a crucial part of our BAU operations in the fraud world that the majority of the time, fraud operations leaders have their strategies on lockdown, and more so than me, right? I'm in risk management. I'm not in fraud operations. So they know more than I do about their fraud environment and their processes, their strategies. Where the lag is, is definitely in controls versus processes. And I think that it comes from leaders wanting to, and not wanting to, but also needing to be efficient, right? That is key in a high-volume, very complex environment like banking. We have got to be efficient or we can't get the things done that we need to get done. We don't have the budget to be doing things we don't need to be doing. We don't have the manpower, and it's just not the most intelligent way to do business. We want to maximize what can we do with the least and the least amount of time. So controls versus processes, for sure. I think that that comes from fear of redundancy, for sure, or not appropriately being able to understand what can go wrong, why
and at the magnitude that it can go wrong. So we will, when we think about risk analysis, we should always think about worst-case scenario. That's not going to be your everyday scenario, right? And I feel like fraud leaders often think about their everyday scenario. So the average number of errors their agents make, the average number of technology failures or expected, you know, technology problems they might have, their average number of fraudulent transactions on any given day guides us towards those decisions. And none of that is incorrect, but when it comes to risk management it's really important that we understand, like, inherent risk—everything going on, going wrong at once, where there's no control, your worst-case scenario. We do discuss a little bit of likelihood and impact, but we always start from inherent. Likelihood, the impact, and all that complicated math comes later when we need to make enhancements to make sure we don't over or under. But we always start from a place of inherent. And I think that that's really hard for fraud operations leaders because they want to say, well, that's never going to happen, though, because I have this, this, and this in place. And it's very hard for them to wrap their head around the return on the investment for something that maybe doesn't have a high likelihood. But we'll talk a little bit later in the conversation about some examples of where that can go wrong, but that is the most common, I think, struggle when I'm at the table with operations leaders and trying to kind of discuss how important this is and make good decisions.
I love that. And it also, I made a note. I don't know if you saw me kind of write down to the side, was like, risk assessment webinar with Angela, because I have one that I created a presentation on, you know, creating and building your first fraud risk assessment and understanding the math truly. And because I was a part of that world where it was like
Curiously jotting things down.
What do you mean? Well, like the catastrophic is the incident that I have to consider here, but that's like never going to happen. How do I really prove and advocate for the product or the service or the solution that I'm trying to bring into my strategy? And so once it finally all clicked, made a world of difference. So, yes, that's my takeaway for this right now is that you and I are going to have to do a webinar on this. Love that. So just to continue to dive in right here, I want to ask, what happens when processes aren't aligned? And I think this is happening, I know this is happening in the community banking and the credit union space for sure. And obviously, big banks deal with this too, but what happens when the processes aren't aligned to the strategy or the controls?
Operational losses. That's the biggest way to say it. But it creates gaps that can either be exploited by fraudsters, which is the number one one that we think of in terms of fraud. But it can lead to, it can also come from not just fraudsters, but just general places in your environment that you're just bleeding. You could have technology, for instance, a good example. And I'm going to mention this one because it pertains to fraud or non-fraud, is ATMs. ATMs, regardless of fraud, ATMs are constantly having to rebalance themselves and money is counted and people go to the ATMs. I'm not an ATM expert, but there's so many. There's a lot of complexities to just an ATM machine that people probably don't think about on a daily basis, right? It's like how does the ATM know how much money is removed and how does it get it perfect all the time? And then how does it get rebalanced, at what frequency. I have a lot of peers that are in more payments risk, and that is something where it has come up several times over the years where tons of money is just lost just because of process gaps in the way that our ATMs work and the way that they're rebalanced. That can absolutely lead to fraud because somebody could be completely. Even internal fraud, an employee that is responsible for doing some sort of manual check or rebalance of that ATM that doesn't have any control behind it. So manual human doing a process could be completely exploiting the fact that they know about that gap because they're internal and they're committing fraud in their own company. It could happen and I'm sure it has happened.
Yeah, I would also encourage anyone who hasn't considered this yet, check your mutilated cash in your teller drawers. I think that's a big blind spot everywhere. But anyways, you made me think of that with the ATM balancing. And because I'm thinking about the processes and the controls there that we have as far as like walking it out and calling law enforcement to bring it out. And that's a process.
Like, how are we controlling this? So anyways, I'm going to digress from there. But I think that this is where, you know, this is the part that really matters is the gaps, not the theory, not the definitions, but the actual breakpoints, the moments where something should have worked but didn't because strategy and control are, you know, because I got to start over because somebody's walking in. I'm sorry. Get out. You see I'm recording. Literally, I'm recording. Please get out.
I love you, please get out.
Start back over. (19:55) Because this is the part that really matters, right? It's the gaps, not the theory, not the definitions, but the actual breakpoints, the moments where something should have worked but didn't because fraud doesn't need your whole system to fail. It just needs that one gap, one disconnect between strategy and control, one process that doesn't align, one delay in action, right? That's it. So where do fraudsters take advantage of this misalignment the most?
So I'll use a specific example that's very public and not very complex because I think that that will be the most impactful and easiest for people to kind of wrap their arms around. And it's definitely the Chase, I’m going to call it the Chase glitch because that's what the media calls it. But it was check fraud. And it's a really good example because I don't know that Chase ever publicly said exactly what went wrong. And it would not be alarming if they didn't, right? They need to kind of keep that behind closed doors and do their own analysis and fix what they need to fix. But based on the scenario, which was people being able to take large checks tied to accounts that did not have money in them or at least not enough money to come close to covering the check, were able to mobile deposit or deposit at an actual ATM and immediately withdraw the funds. So based, and they're off with that money, $100,000. And then we have all these accounts that reactively are frozen, but the money was already gone. Again, preventative versus detective controls. Okay, great that you realized it happened. That money's already long gone and you locked up the account, but nobody's coming back to that account. They're already gone with the money. So it's very, very much reactive, but several things could have gone wrong in that scenario. It could have been, or multiple things. It could have been a strategy issue. Perhaps it was very intentional that they did not want to hold the checks. Maybe there was customer experience concerns or (22:06) wanting a small amount of money to be available to our customers, maybe feeling like that was a lower-risk concern. So maybe there were some controls in place that did kick in, but didn't cover the kind of the intensity of this situation and the volume and the dollar amount of this situation, or it could be that there were check controls in place that were supposed to detect that these were fraudulent checks and they didn't deploy at all or they didn't deploy appropriately. Either in any of those three scenarios, which all three also could have been in place, they were able to be exploited. And where the Chase glitch one is important is it proves my point about a situation where the bank probably planned for some bad checks, right? They probably plan for, sometimes customers are probably going to deposit these checks and not quite having enough money to cover it because that's quote-unquote normal. That's expected. That's our average behavior. What they didn't account for was that going viral, which is also not a new thing, right? It's not a new thing to juggle that balance of letting people have a certain amount of funds and there being a little bit of acceptable risk that we factor in. But what they didn't plan for, what they may not have planned for is what happens when every single customer or a large amount of customers all at once. (23:59) In really large dollar amounts, like hundreds of thousands of dollars, not Hailey needed to pay a $200 cell phone bill and try to kind of cheat the system to be able to pay the cell phone bill. She's going to hopefully deposit the $200 in a couple of days and it'll all work out. They were not planning for the catastrophic, you know, large percentage of customers, large deposit, large dollar amount checks all at once. So that was, was either one or many gaps that was definitely fraud, whether it's first-party fraud, et cetera, fraud, and the gap was exploited. One or many gaps were completely exploited.
100%. And so what would you think would be like early warning signs, you know, that a gap like this exists? Is this something that we have to wait until the fraud happens or are there things that we can do now to really look at our program, our strategy, our controls, our processes now and determine, hey, there's a gap here. Is there, are there those early warning signs and is there something we can do about it?
Yes, it absolutely should have been considered in the original planning of this process and what controls were needed. Because when we go back to what we know about inherent risk, we're thinking about our worst-case scenario and this should have come up. If it did not, from a control performance monitoring perspective, we want our, we want controls in place that are as real time as possible. It could be thresholds. Therefore, we're not looking at every single transaction, but we are looking if our volume spikes in a way that it normally would not. The reason that I like thresholds in terms of that broader monitoring is because they catch a lot of things. If there was a systemic error that causes a volume of something to spike, you're going to catch it in real time. If it is fraud, you're going to catch it in real time. Because you're just going to go in and look and want to know why the activity spiked out of what was beyond what was normal. So it could be that this happened at ATMs in very condensed areas or perhaps it was the dollar amount of the checks on that specific, you know, one- to three-day period could trigger something. There's the checks being tied to new accounts that were just open for this sole purpose. That's why we put so much due diligence and maybe make different decisions and strategies around new account opening. But absolutely, as real time as possible, being able to detect things so that in addition to everything that you've thought about when you did your strategy, your process and control and risk analysis, (27:25) go in a way that you did not expect and account for. You are covered because we aren't, it's very unrealistic. As much as I'm putting in like all this verbiage about doing appropriate risk analysis as a risk manager, I know, and I think this came up on our first episode together, that you cannot predict every scenario and you can't test every scenario. So that's why those, the real time and the thresholds and those performance indicators, that you can react and having a way to react to them as quickly as possible, look into it and react to it is very, very, very crucial. And that ties back into our efficiency as well being so important.
Well, I think too, yes, we can all speak and say, well, they should have caught this, whatever, but you're right. This is all lessons learned. So whenever a new trend happens, whenever a new glitch fraud actually happens, our role as fraud and risk leaders is to take that industry knowledge, learn from it, and then add it to your strategy to say, yes, they missed this. Here's how we can learn from it. And here's how we're going to adjust our strategy.
The other thing that I wanted to call out that I think is, you know, one of those things that at least I keep thinking about as far as like the thresholds that you mentioned, I think that it is so simple, but at the same time, it's so genius. Like we think about ATM jackpotting, right? When that happens, you've got an alert that's going to set off or even the alarm on the door, it's going to go off and tell you, hey, the door is open when it's not supposed to be. But do we have things that say, hey, you've got, you know, a hundred customers, you know, and that's small compared to how many actually did or participated in this glitch fraud. But setting that threshold to say, hey, this is like an influx in activity, something's off here.
Right, right. And I don't even know if numbers are all that important. Or something could be off and it should be something that you're easily able to look at so that you can then just walk away if nothing's off or implement whatever your plan is. And I also want to add, it's really important that I'm not picking on Chase as a bank. Whatever happened, because again, we really don't know what actually happened, but whatever happened could have happened at any bank. I've worked at so many banks and that's why this is such a great example, because it's such a very simple and straightforward process that exists at every single bank. Most banks approach it pretty similarly, customer experience versus risk versus fraud, et cetera, and are just looking to get that timing right. We want to serve our customers right. We want them to be able to have access to their money quickly. We want to show them trust and convenience. But we want to also understand the risk. And that risk can come from our legitimate customers, fraudsters, people that started out as legitimate customers and then turned into fraudsters or do fraudulent activity. It really could have happened anywhere. That's why it's such an excellent example. It's not specific to a nuanced risk that exists at one bank or a nuanced process that exists at one singular bank.
So true. What we're talking about is not hypothetical. This could happen to anyone. You know, fortunately for the little guys, unfortunately for the big guy, they try to attack the big guy. And who knows, maybe this happened at a smaller credit union community bank first. And they were like, this is a good one. Let's see if we can get away with it at Chase. But we'll never hear about the small bank that it happened to, you know?
So I definitely want to say that I 100% agree that this is not just the one-off that would happen to a big bank. We're talking to every financial institution right now that it's important to learn from these big attacks that happen and adjust your strategy going forward.
Exactly. And this is an example too of like singular average amount versus influx. The reason that this made it to the media, because again, this is not new, small groups of people probably do this on purpose all the time, and then they switch banks, and then they get caught, and they do probably go to court for minor check fraud. But because of social media, and this becoming so viral, and the way that whoever started putting it on social media marketed as more of a glitch instead of a fraudulent crime, it's like it really took on this entire life of its own and something so simple became our worst-case scenario.
So true, so true. So we've talked through, you know, where things break and now I want to talk about where this can actually work. We're going to shift a little bit. You know, we talk all the time about layered controls. You were even mentioning them a little bit earlier in the podcast and, you know, fraud programs or layered fraud programs. But I think sometimes what we really mean is we added more stuff, you know, hey, this is more and more doesn't always mean better. Though someone even posted on LinkedIn earlier about adding more versus having a true understanding and getting rid of the things that you don't need. So I want to talk about what a true layered approach actually looks like when things are aligned correctly, because this isn't about doing more. It's about making sure that what you have actually works together. So what does it look like when controls, strategy, and processes are actually aligned?
So what it looks like is your process and your steps are all occurring. You have looked at that process. You have looked at efficiency. So you have looked at, do we need to keep this manual? Do we need to switch it to automated? And you've looked at where your process gaps are. Process gaps are super important because what I've often also seen happening, which completely throws out your layered approach, is operations leaders feeling like, well, I don't need to fix that in the process because my control will catch it. Well, you just threw your layered approach completely out the window and now you're trying to misuse your control as your process. And that's, so that is where the sound layering is. Every layer truly has a focus on quality and working as it should independently. Because if each layer doesn't work the way it should independently, it's not layered anymore. Somehow, somewhere, someone is bearing more weight than they should. And a good example of that, I love examples, is cars. Cars is another favorite example of mine. You have your regular brake and you have your emergency brake.
Sound layering is Angela making sure that her brakes are always working, her brake pads are always changed and tested, quality-control tested, so that on a daily basis the process of my car braking works as it should. The control is your emergency brake. So I might go my entire life without ever having to use my emergency brake, or maybe three times in my life, have to deploy my emergency brake and use that to stop my car. What should not happen is Angela needs her brake pads, but she's lazy. She doesn't want to go get her brake pads replaced. Maybe she's on a tight budget, whatever the case may be. And I start just also dangerously using my e-brake as my brake. So I'm like, I'm going to use, I know my regular brake's not working that great, so like then all day, every day I'm trying to use my e-brake. So that is where the layering gets messed up and the importance of each each layer being sound and accurate independently because a control is only as good as the processes that it's over top of. And if you try to use the control as the process, you're not layered anymore. You've taken yourself down to a single layer because what's gonna happen is that e-brake is meant to be a worst-case scenario. And so many things can go wrong if I'm misusing that e-brake. I'm gonna wear the e-brake down, or maybe the e-brake is not meant for that tension of being used all day every day and it's going to break off in my hand. So there's like so many reasons why we shouldn't do that and it completely interferes with the actual layering that we're talking about.
So how should strategy inform what controls are in place?
So I don't necessarily know that I would agree that we would say that our strategy informs what controls are in place. It's definitely more your processes because from an actual fraud operations perspective, right, we have our fraud processes, so if something breaks there or your risk entry points within those processes are where you want to put your controls. You're still going to think about your strategy a bit because, again, your strategy is like your rules, your alerts, your intentionally saying I'm going to do this over here but not over here for these reasons. Where the controls would maybe come into place with your strategies, however, might be if you have made a strategic decision. And the Chase glitch, we'll kind of go back to that one. If I've intentionally made the strategic decision to not hold a check that is a lower lower dollar amount because it's lower risk and I don't want to interfere with that many customers having availability to their funds. And I feel like based on historical data, my greater risk is larger dollar checks or larger dollar checks for new customers. And I want all my control, my, and I'm intentionally saying my strategies are going to deploy this way in this higher-risk environment. What I might want to make. What I, not what I might, what I am going to make sure I still make the decision of is still having some type of control over that lower-risk area because we know that fraudsters like gaps and what fraudsters often will do is if they know that we are going to deploy strategies, rules, alerts, holds based on higher dollar amount or a certain volume or newer accounts, (39:07) is they will intentionally conduct their fraud in such a way that it gets around those things. So you don't want a fraudster being able to then just do lots of low-dollar checks because they know they can have the funds immediately that is then going to add up to just as much money as one larger check. But the fraudsters are smart enough to figure out that your strategies are probably going to allow for them to do it this way. So that's where in that area you may have made a certain strategic decision, but you still need a control in that lower-risk area to cover your worst-case scenario because then your lower-risk area becomes a high-risk area instantaneously. You got it wrong, misjudged, misestimated, which is okay. We're not always going to get it right, but if you have the right control in place, you should be okay either way without interfering with your strategy and without interfering with your legitimate customers who really truly do just need access to those funds for more lower general dollar checks. Does that make sense?
Yes, it absolutely does. And so again, I'm just kind of like circling back to like the layered approach and definitely want to ask, you know, as a practitioner or former practitioner, you know, how could teams tell the difference between a true layered approach versus just adding more controls or that redundancy that you're talking about?
I think it's really understanding the why behind something, constantly reevaluating to clean up your inventory. And sometimes it's also just the how. And what I mean by that is I have seen where large reports are being pulled all day and we're looking at every line item on that report, which takes hours for a person to do. So that's a manual control, it's documented appropriately in the inventory as a control, but it's that one person's full-time job all day long. They're going over this report, right? So it's not that we don't need a control there, but it's do we need that type of control there? So the other element is, okay, has Jane been looking at this report every day for several years and never has she had to flag a thing, right? That tells you that that's an inefficient control. It's really expensive because Jane's all-day job is looking at the report. We're paying a hefty salary for that. We haven't had any reward for it, but we don't want to get rid of the control completely because again, we're planning for worst-case scenario and like as soon as we pull that control, who knows what could happen. That could be the one time, of course, in a decade where there's some type of systemic technology breakdown or fraud event. So it's more, well, can we flip that and look at the how? Can we set up a report that is more of an exception report, where instead of Jane looking at 300-plus line items for a mismatch, we take the same report and layer on some type of automation or reconciliation, where you only get kicked out if there's actually a mismatch that you need to go in and look at.
So that's running all the time. So it's there, whether there's an exception every day or whether there isn't one for 10 years, that control is running all the time, but it's a lot more efficient and targeted because I'm only having to actually take action if I'm alerted and something is kicked out that I need to look at. So it's often not maybe eliminating a control completely, but changing how the control works and what it looks like.
I love that you're already turning this into practical insights that can be taken away today. The phrase I just wrote down was efficient and targeted. I love that. I think that I'm going to answer my next question for you and then I want you to build off of it. But one of the things I was going to ask is what's one question that the team should ask or a fraud leader should ask their team tomorrow? And I think part of it is your Jane scenario is ask your team why they do their day-to-day task. And if they answer any of those questions line by line and they go, because we've always done it this way, that's one that you have to look at right now. That's one of those things that we need to understand why we're doing it, how we're doing it, is it effective and targeted? And if it's not, how do we fix it? Maybe like you said too, we're not getting rid of that process,
but maybe we just adjust how we do it because of X, Y, or Z whenever we factor in the overall thought process. So I'd love for you to build on that.
Yeah, so definitely I love the why. So I'm a big proponent of why. Why are you doing it that way? And like you said, the answer, well, we've always done it that way, is not a good answer. Like, what's the real why? And most of the time, your why is going to speak to the risk you're trying to mitigate or the efficiency you're introducing, whatever the case may be. You know, what historically have the results been? Are you finding anything? What are you finding? How often are you finding it? And also when the person is finally able to articulate a historical why, does that need and risk even exist anymore? Because what I've also seen, and this comes back to, this is actually a great full-circle moment where you asked me about the alignment of processes. So often when we think about processes, especially in large financial institutions, there's a lot more silos and separation and hands in the pot and teams in the pot. At a smaller community bank, you might own a lot of things and you have a great holistic view of how things connect to each other and et cetera. In a large financial institution, an end-to-end process can be segmented out into several different organizations and owners, and all of that. So a team might have implemented a control to mitigate the risk of a specific part of a process that has completely changed. So the risk either doesn't exist anymore or it has completely changed. And if your risk has changed because a process step has changed, moved, et cetera, then your control has to change. So a good example goes back to manual versus automated. The risk in a manual control (46:29) is going to in detail look different than something that's automated. So it doesn't mean that the control goes away, but how you manage the risk needs to change because it is no longer a human risk and the steps in the process might even look completely different, but it is now a technology risk that has come into play. So how you manage it is going to look differently.
Yeah, I love that breakdown. I think that it really is providing that insight into like our everyday processes, the things that we do now that maybe we aren't considering. And, you know, I have a feeling that there are, you know, some that are listening that are realizing that they might be mixing, you know, these things up. And so, you know, I want to ask either like, where should they start or what's a quick way that they could identify if controls are disconnected from overall strategy?
I think a really great foundational exercise, and this is really common in the larger financial institutions, is good business process management. Do you have, and I personally love a good visual, so a nice visual process flow where you actually talk through the steps of the process, how are they each defined, and then what could go wrong at each step in the process, and then mark it with a quick note. That's a risk entry point. We might need a control there. Once you've done that process and risk assessment, then it comes into, what will our controls look like at each of those risk entry points? How will they work together? How will they work as standalone? Controls can always be bypassed. So in the life cycle of fraud, we're thinking about, you know, originally we want good controls around new account opening and authentication or identification at login and all of that good stuff. But once they've penetrated into the bank, then we want our controls around transaction and money movement and actual account activity that's taking place. We want to be alerted to that. So every step of the way, if something was able to be bypassed, there's something else that kicks in and really focusing on a solid foundation. Once your solid foundation is there, it's a living, breathing cycle of, okay, we laid down in this 12-step process, we've got three or four controls that are tied to it. Now this situation has popped up and (49:30) there's another gap that we didn't account for. So we're going to add another control there. And then that might cause us to question a control that possibly happened ahead of that one. And do we need it anymore? Or was it in the wrong spot and we can completely pull it out because it didn't add value? Or do we still need it there to feel pretty good about the layering of our controls because we layer horizontally and vertically, and we just need to enhance something in that control in addition to adding a new control. So it's a living and breathing process and really it's inventory management: making sure you clean house, get rid of controls you don't need anymore, deactivate them, pull them out, implement new ones when you need them, and always be coming back to your foundational assessment so that your control inventory stays efficient and accurate, doesn't become redundant, works together really well, it's nice and clean. The more cluttered it gets, the more you just completely lose sight of your foundation. So that foundational kind of exercise and assessment and then being aware and willing to understand that that then becomes a literal living, breathing assessment that you look at all the time. Different things can trigger you to relook at it. It can be losses. It can even be procedural. It could be complaints data, a spike in complaints data that's coming in, your false positive rates. There's all kinds of things that can cause you to go back and relook at it, but not just having a set-it-and-forget-it mindset and always being willing to come back and revisit that foundational assessment.
I love that you called out the process mapping. Like when I remember the first time that, you know, it was part of an exercise that we were having to do and I was like, this is the most god-awful, boring thing I've ever done. But then at the same time, I, as we were like going through one of the things too, was like trying to understand the payments flow, right, within the organization, which for me, at the time, I was like, yeah, I need to know this because I need to know at what point is the last time I can, you know, interject or something to stop a fraud transaction from going through. So like that's my last point of control is here. And then we realized, too, that there was maybe an infrastructure issue that we didn't know about, because at a certain point when we were looking at the ACH flow, it was, no one knew what happened to get it from here to here. And we were like, how do we not know this? Like what in the world? And so that really helped us to have that foundational understanding of, okay, this is where we sit as an organization. And then in this process, here's where, you know, you've got the operations team that pushes this button. And if they're not there to push this button, what happens? And then, you know, for the fraud aspect, yes, we look at it and we're like, we've got to make sure that this, you know, still will flow and still works and that it will then move into our alert system or blah, blah, blah. But then we've also got, you know, business continuity that's like, but we've got to make sure that ACH is posted. Like, what are we doing in the backup? So I so love that you called out that exercise. I think it is truly one of those things that if you haven't done it yes, speaking from experience, it is boring but you have to do it. And once you do, you'll realize that there's things that you didn't understand about your organization and things that you didn't realize where you had access to to stop fraud or to intervene. So I just wanted to call out that I love that you called that out.
Thank you. Yeah, 100%. It's business process management and how it connects to control management, how it sits under an overarching umbrella of risk management. It can be very boring. I try to be charming and funny throughout my risk management guidance, but it is really important. It is very, it is really interesting. And once you understand it and it clicks and also the heavy lifting is in the first time you tackle it. Once you have the inventory of process flows, once you have a good inventory of controls and the performance monitoring, if it all fits together nicely in this perfect world, it becomes so much less stressful and so much easier to understand, find things and make good, well-informed decisions and do it quickly. If every time chaos happens, at that moment you're like, my gosh, where is it happening? Is it happening in my shop or is it happening in the payments processing ACH shop? Like what is going on? If you have to stop and try to do it in that moment of chaos, it slows you down. It slows you down so, so much. And it becomes such a stressful, not fun, costly game of whack-a-mole. And it might seem like that game of whack-a-mole is the better path and the path of less resistance because it's like, look, I'm just gonna deal with it when and if it happens and that's my efficient and targeted approach. It's like then you might be able to actually tackle whatever came up in that moment, but if you don't set up the foundation and there's no record of that, it's gonna happen to you again and then you're not gonna be able to remember exactly how the heck you tackled it in the first place. Maybe the old (55:40) team quit or whatever, so you end up solving the same problem over and over again or it's just very messy and time-consuming to try to sift through. It is so well worth it to do that heavy lifting and set a good foundation up and then go into more of like this calm, organized, well-oiled-machine maintaining mode, which is just a much happier and better place to live, I promise.
I love that and appreciate it so much. Any parting thoughts or words for anybody that's listening that you want to make sure that if they take one thing away from this conversation, what do you want that to be?
To really understand the difference between business process management versus control management, to be very, very cautious of redundancy versus efficiency. Really ask yourself, is this redundant or is it an appropriately layered approach that comes from a need, and to just make sure that you are always coming back to that analysis mindset every time something happens so that you aren't just like plugging that gap, putting a Band-Aid on it, but looking at your foundation and what you may need to change there. So not what you need, not what your action plan needs to be at any given moment, but does something need to change in how you've actually set up your foundation? Being willing to embrace that as a constant mindset.
I had a thought and I started to giggle and I was like, I don't want Angela to think I'm giggling about what she's saying. My thought was as I, you know, thinking about how I would do this now, and, you know, a part of me is like, I've sat in the shoes and I know, I know how much of a struggle it is for fraud fighters to advocate for them to have anything. And because it does feel like
we just need more. We need more of this or that so that we can have that layered approach. And so one thing that I would do, like if I could go back and sit in the practitioner's seat, I think one of the first things I would do is I would participate in like a vendor management thing with risk or with whoever. And I would want to join the call and I would want to say to every vendor that we have, what do you do for us? And then
Obviously compare it to that contract, make sure that they are doing what they say they're supposed to do. And if there's a fraud function that's included, but maybe it's not enabled, but you're paying for it. Like you don't know how many times that when I did go through a vendor management process, there were like, yes.
This could be a whole nother episode. That's a very good point because we didn't even go down that path. But our whole discussion in this hour was built on our own internal controls that we own and operate within the bank. But when you outsource, when you don't have line of sight, that brings up a whole other discussion of lack of line of sight and then who's accountable. So yes, that is very, very tricky and it's very important in a world where, like fraud risk, where we do rely
on vendor management so much.
Okay, so second takeaway from this is Angela and I are going to come back for a lack of line of sight and vendor management conversation because it's so important. Like everything truly fraud risk, we are the ones that have that overarching holistic look of how things operate within the organization. We're in the best possible position to advocate for ourselves. And even if we are just thinking about the internal processes, the internal infrastructure,
how we operate, why we do what we do. When we factor and consider all of those things, we really are in the best position to advocate for what's needed, what we can do, what controls are missing, where the gaps are. We can see all of that. We just have to do the steps and we have to have that foundational knowledge. So Angela, just, I really can't thank you enough for bringing this topic to the show. I think it's one that will resonate with a lot of the listeners and one that really made me pause and think. So I appreciate it.
Thank you so much. Thank you for having me. It is always a pleasure. And yeah, to be continued, because clearly we have more to talk about.
Clearly. Yeah, yeah. So the takeaway, I think for today, and correct me if I'm wrong, but the takeaway is, you know, controls are not a strategy. Strategy without process doesn't work. And process without alignment creates gaps. And those gaps are exactly where fraud wins. So for all of you listening, you know, if this episode made you pause or rethink something in your program, don't keep it to yourself, you know, send it to your team. Start that conversation. Pressure test, you know, how these actually show up in your environment. And, you know, if you want more kind of real talk, make sure you're subscribed to Fraud Forward, obviously, and the Monday Fraud Fix. Connect with Angela and me on LinkedIn. And yeah, so again, thank you so much for being here, Angela.
Okay guys, stay vigilant, stay informed, and keep moving fraud forward.