Speaker 1: Here's a quick introduction to risk management. Now first off I'm going to address the elephant in the room. I am the person who least likely looks like a process engineer, well I look like an engineer, but a process person from an operational risk perspective. I assure you I have 10 plus years in operational risk management and before that I did a lot of technology risk. Think of me more of the eclectic engineer than the office worker. I'm coming to you, by the way I'm Justin Hitt from Inside Strategic Relations, I'm coming to you with an introduction to risk management. So first off what is risk management? Risk management is your ability to foresee negative events in the future and build into your process today controls or checkpoints that are going to prevent you from from having that problem show up. You're going to see a broad, almost an unlimited number of possible problems. What you've got to be able to do is based on the risks that your process faces, narrow down those risks into what we can address. In some cases you'll accept certain risks and in other cases you'll control for those risks. Now I'm going to give you a layman's view of risk management because I often see that the businesses don't understand the concept of controls and they see it as something separate of their actual process. So every business has some core deliverable. That deliverable has laws, rules, and regulations that govern the quality, the performance, the you know what can you claim, how you handle data associated with the deliverable, and your process builds the deliverable. There is a loop here. So you have process, controls, deliverable, but it's a circle. You can start with the deliverable and the laws, rules, and regulations are a characteristic of that deliverable as well as the performance and function and other elements that make up what that widget or that deliverable is. But your process is how you implement it. Your controls are how you check your work. So let's say you're doing banking services and you have a mortgage company and the controls associated with that are gonna have to do with a lot of laws, rules, regulations. There's Fair Lending Act, there's anti-money laundering, there's a Bank Secrecy Act, there's privacy. Privacy is a big thing and then there's probably like 15 more other items. If your element is the application process, the deliverable of an application process is a completed application that is truthful and has substantive evidence that the person making the loan or the person applying for the loan and the company making the loan are both, it's a good deal. So from the applicant side you're gonna have their financial information, their home address and phone number, a lot of personal identifiable information. Law requires that you protect that information and that that information be accurate so the bank would actually have some kind of obligation to check the details. You know, did you look at their driver's license to see whether or not the person applying for the loan is actually the person who will be paying back the loan. Okay, so these are the concepts that are inside the environment. What risk management does is takes the process, it doesn't add to the process, so a step in the process is the control that would verify both the risk condition, is the person applying for the loan the same person who can pay back the loan. You know, because there's a money laundering thing where you buy a house and you take out a loan and then you refinance the loan and you put dirty money into repairing the home and then when you refinance it you take the dirty money, you take clean money out. That is a function, you know, when you're applying for loans you may not know this the bank's doing this, but that's a function the bank is responsible for checking on to make sure that you haven't done something or be on a certain list or something to to not be in a good condition to be the applicant to a loan. Now, on the bank side, all of their loans put together can't exceed the amount of money they have available to lend out. So again, there's a process and controls there. The control has to be a part of the transaction rather than an extra piece of work. So a lot of a lot of business units make the mistake of believing controls is something other than what they're doing and this is constant. I constantly see this. A business will have a control they actually never use. So if the control is tied to a law, rule, or regulation and they never actually check against the laws, rules, and regulation, that creates additional risk. And so essentially a control that has not been used needs improvement. The main improvement is to actually use it. A control without enough evidence to prove that they're using it is also needs improvement or may be ineffective. The only control that matters is the control that is regularly used in the appropriate way to reduce risk. So you're gonna detect or you're gonna prevent risk. I know this is pretty dense. Again, that's why I want to give you the layman's overview because in 10 plus years of doing this stuff and then maybe 20 years including the IT side, there are nuances that folks don't get. So what I'm, the reason I'm recording this is because I've always found that that one-on-one conversation with the business person helps them understand that the only control that reduces risk is an effective control that is being implemented as designed. And that design, in order to be effective, must take into account accepted risk, laws, rules, and regulations, the appropriateness of the control for the the deliverable at hand, and then ultimately that it's actually implemented. Okay, there's a lot of controls out there that are not implemented. A control is always going to talk about the who, what, why, how, those elements of the risk itself. So if the risk is protecting, if the risk is a leak of personal information of mortgage applicants and the law is a privacy act in the United States or in a particular state, then your control must effectively do this for the applicant. Who's gonna do the work? Maybe there's a privacy officer who's gonna verify the information. How are they gonna do it? You might seed the the applicant list to see if those names ever leak out into the public. You might have a verification process to make sure the applicant is who they say they are, and then storing the information in a system that is secure. Maybe you're hashing Social Security numbers or you're encrypting data at rest. Now again, I don't look like the typical office person that knows all this stuff, but think of me as the engineer. I really get down into the process. I look at the segmentation of duties. You don't want the person checking the ID who is also checking whether the IDs are properly stored in the system, because if they make a mistake, they can go in the system and change it. We don't want that. As an introduction to operational risk management, we don't want the businesses doing anything extra. The control is part of creating the deliverable. It could be quality control, it could be a quality assurance, it could just be a functional control, but if the control was not done, we've elevated our chance of risk. So in the money laundering situation, if someone comes in to get a mortgage and they have brought in, maybe they got $20,000 in cash to buy the house and they weren't able to prove where the money came from, that could be a suspicious activity report, it could be a lot of other things that needs to be looked at. If the applicant is buying a house that far exceeds their documented income, then that is a possible issue. Even though they might be putting 50% down, let's say the proceeds from a sale of a previous home allows them to put 50% down on this big massive home that they're purchasing and then they have a history of flipping houses. They could be a real estate investor or they could be money laundering. We don't know that. The controls are in place to do so. If those controls are not in place, every applicant builds up the liability of the mortgage company who is the regulators. You're kind of beholden to the regulators not to be money laundering. So every applicant that isn't checked, risk increases. So the risk is often the foundation of process design and the control is a backstop to reduce or mitigate that risk. These concepts come together in day-to-day activity, but when you're on the business side and you're working with a control officer, for example, you have to understand that control officers not trying to, some are, but a good control officer is not trying to create extra work for you. A control officer wants you to have the most efficient and effective process and for a process to be effective you need to know what deliverables being produced, what laws, rules, and regulations are applicable, and then ultimately how do we control for the risks created from those laws, rules, and regs. Here's a secret that I often see and a lot of people don't understand is if there's no risk or no deliverable or no controls, there's no work to be done. So in the case of the mortgage application, if you've implemented an automated system that you're a third party that verifies the authenticity of the individual, maybe runs a quick criminal background check, runs a quick, you know, money laundering databases are available, might run a check against political parties, you know, we don't want the the child of a dictator buying houses in the United States to store illicit funds. So there's import-export restrictions. All that might be done manually in the beginning, but then now it's being done by a computer system. You can drop half the steps out of the process because a person doesn't need to go look up this information. The automated process might actually be more efficient, but now we need a control to check the automated process to make sure it's actually doing what it's supposed to. I can't really go into details, but there have been times where pre-clearance databases didn't get updated. So the control was functioning, the system was available to check applicants or other or new hires or whatever's going on in a pre-clearance database, but the database wasn't updated in two years, therefore the records are not accurate. So in the control design, because it was automated, people assume there's nothing else to do. No, you need somebody to go through and check the last update and make sure that your records are no older than a certain amount of time. In your opt-out privacy regulations, some states have like a 15-day, you know, from the point someone says I want to opt out of your mailing list, some states have like a 15-day, it better be out of your database. Other places have 30-day. Some countries have, you know, when you get around to it. But ultimately, you've got to decide as an organization, are we going to check from the date? So there's one way for people to ask to get off of a mailing list, or there's a set of ways. From the time they ask, are we going to set the clock at 15, 30, or whenever we get around to it? Well, if one state has 30, you know, or one state or one country has 15 days, you might as well check 15 days for everything, because it satisfies the other conditions in which regulations apply. You know, one of the reasons I do these types of things is because I do have more than 10 years of experience in operational risk management. I've done business development, so I've sold these types of solutions from the IT side primarily. It can be very complex, but the business who understands that this is a part of keeping us out of trouble, and actually quality controls or effective controls mean less work, then you're able to create them more readily, to see the relationship between your controls and deliverables, to see how you get better quality deliverables, and actually it takes less inputs. The last point I want to cover is that of effective controls. I keep saying effective controls are the only control, and it solves so many problems down the line. If you do not have effective controls, first off, it's going to impact the deliverable. Second, there's a possibility of having a regulatory issue. So the ineffective control is not performing to reduce risk, it's not performing to detect risk, and in the testing of this thing, or the validation of this thing, you find out there's a gap. That is a buttload of work when you have an issue. Now, some businesses want to avoid the issue, but again, when we're talking high dollar transactions, banking, finance, fintech, technology services, the regulatory fines could be billion dollars. They could be hundreds of millions of dollars. It is cheaper to have the effective control up front, to implement it appropriately, to monitor or to validate it, and then not have an issue, because there is no issue, than it is to find an issue and hide it. A lot of businesses will find problems that they're going to fix later, or as a control officer, I'd be in an environment and they'd say, well, future state, we're going to do X, Y, and Z. Well, regulators don't care about the future state, they only care about now. If your control is an accepted control, it's tied to accepted risks, you have a rationale for having the control and the risks, and you are not implementing that control, that is like a sin, and you should be fined. Now, if you can find that internally, and then put those on a list, and then prioritize and start fixing those things, you can improve the process, reduce the risk, and operationally be more functional. The challenge becomes, and this is the, this is why I'm putting my face with this, because again, I don't look like a office worker. I have a farm, I'm more of an engineer, eclectic side, but the human element is the biggest problem in business process ever. Companies try to save money by outsourcing processes overseas, but they don't take into account the different laws, rules, and regs that are associated with, and now they're running bank transactions over the telephone in a foreign country that provides private information of the individual in the other state. So the citizen of the United States is conveying private and personal information to somebody in the Philippines, and they've now violated a international law associated with personal privacy. So the desire to reduce costs is a pressure that businesses face. The limited staffing and resources is a pressure the business faces. The business faces a pressure of inappropriate or non-functioning automation. So we thought we automated the process in the past, but over time things have changed and now don't work no more. You don't want to add internal audit, you don't want to add a regulatory body, you don't want to add a fine or consent order on top of these other pressures. So by adding a personal face to it, I really encourage product managers, business managers, anybody in the operational side doing work, not that the risk management isn't work, but ultimately if you're in there creating the deliverable, I want that open pathway. I don't want you to fear your control officers or your or your internal ITV or different types of testing teams. I want you to see them as a resource that you can pick up the phone and say, look this new regular, I'll give you an example, privacy. Privacy went from one federal law in the United States to almost every state. 25 different states up front had their own little privacy acts. California in particular, their privacy acts pain in the butt. But now you've got a European Union, Asian Pacific, if you're an international bank you got all these areas, I understand how much pressure you got on you, you need that outside set of eyes in order to say, okay, well look, you know, Latin America and European Union, they have a common rule here that is actually, if we meet that law, then we'll also meet the law in the United States and we'll meet the law in Asia. Okay, great, that element's put aside. We're going to build our control based on that. Businesses sometimes might have a regulatory, so international business, and then some country comes along like Canada or Australia and says, hey look, we got a privacy law and you've got to follow it, and it's really strict. You need somebody on the outside who can say, well do you even have any customers in Australia? Are you doing business in Canada? If they're not, then you can accept the risk, set up a control that looks for customers in Canada, and then ultimately be done with it. You don't need to do, in the case of privacy, doing a do not call mailing list registry or anything like that. You can focus on the key factors of the customers you serve in the countries, the laws applicable to the countries you serve. Another factor is costs. A lot of businesses are under that budget pressure and they don't see that better controls actually reduces their costs. Now when a company gets a regulatory fine, the business unit doesn't pay it directly. It's not like they cost back the fine. The business unit will likely get re-org'd and everybody fired, but ultimately, could we have avoided that cost up front with a cleaner process, clearer deliverables, and ultimately better controls? Again, that's a circle. It doesn't matter where you start, you just have to go to the next step in the previous step. So if you start with controls, you have to look at, well, how does the control impact the deliverable and what characteristics of the deliverable are under regulatory scrutiny? And then, of course, your control, where does it fit in the process, and is it transactional part of the process, or is it something extra the business has to do? We don't want anything extra. We want the business to be able to do what they call business as usual, BAU, and at the same time, with different employees, so you're going to have staff come in year after year. Are they reducing risk as a natural component of the business activity, rather than this extra supernatural component? So many business units that don't take the time to get on the phone with me, they really hurt themselves. They may have two different regulators come in on the same process, and then rather working with a control officer who's going to mitigate the, you know, the evidence is the same for both of the regulators, the control officer can mitigate those interactions with the regulator and help the business focus on what the business does, but if they don't trust the control officer, or they're not transparent with the control officer, because most businesses lie about what they're actually doing, then we're just going to have bigger problems in the future. So I hope I've put a face on, we're just regular people in the control, the operational risk management, technical risk management. Some are better looking than me, but ultimately I am what I am, but the key is get past that control as a separate thing. Focus on effective controls for applicable risks, and then build into your day-to-day activities these things that mitigate, reduce, and detect the risk. That way, if there is a problem, you know up front, and you could do something about it, rather than waiting around to a regulator come along and tell you. It is the nature of a regulator, or an auditor, to find problems, okay? It's always best if they find little tiny problems that are easy to fix, rather than critical problems that could be, you know, rate your process or controls ineffective, you know, regulatory fines. It's just so much better for them to find something tiny. Finding something tiny satisfies them all the same as finding something big, but when they find something big, it has unintended costs and actually impacts labor. You know, if you didn't have the labor to get it done right the first time, then you don't have the labor to fix it after someone figured out it was broken. I'm Justin Hitt with Inside Strategic Relations. If you'd like me to go into more depth about risk management, this is an area that as a small business owner, or even as a large manager, you're gonna make your life easier by having good controls in place. Effective controls kind of are like the backstop for the problems that businesses usually face, and they apply in more areas than just operations. But again, I got 10 plus years operational risk experience, nearly 20 years of technical operational risk, but there's also some business development in there, so I want to sell you on the idea that this concept is not that hard, that there are resources available to you within your organization, that's your control organization, and that if you will work with them on a personable level, or a personal level, rather than us versus them, you will get results. And those results are gonna save you time, they're gonna save you money, and they're gonna help your organization be more effective in the deliverables that are necessary for your group. It is gonna be the pathway to profits when it comes to business operations, but it takes a little different mindset, and that mindset is more holistic and less, you know, the policy is important, but is it the right policy for the application? Has the business accepted the risk? Is the process creating a deliverable? Do we have controls in place to close the loop? If you have any questions about what I've covered today, visit me at www.insidestrategicrelations.com. Go to the contact page and ask your questions. This has been a quick introduction to operational risk management and some nuances that are gonna help your life be better. I'm here to help you transform business relationships into profits, guaranteed, and don't ever be afraid to ask questions. I love answering your questions. Ask them in the comments below. See you in the next video.