In our first episode, Troutman Pepper attorneys Keith Barnett and Carlin McCrory welcome Nacha Senior Director of Network Risk Management Jordan Bennett to discuss Nacha's recent request for information (RFI) and request for comment (RFC) regarding ACH risk management.
Troutman Pepper's Payments Pros podcast offers insights from Troutman Pepper Fintech and Payment practice group attorneys, industry business leaders, and regulatory experts on the most challenging legal and regulatory concerns confronted by participants in the payments industry — including everything from BSA to EFTs, fintech to regtech, licensure to lending, Nacha to the CFPB, and payment processing to debt collecting. Our attorneys, industry experts, and regulatory insiders walk you through the federal and state regulatory, legal, and business intricacies of the highly complex payments industry.
In our first episode, Troutman Pepper attorneys Keith Barnett and Carlin McCrory welcome Nacha Senior Director of Network Risk Management Jordan Bennett to discuss Nacha's recent request for information (RFI) and request for comment (RFC) regarding ACH risk management.
With the June 16 deadline to provide comments quickly approaching, Keith, Carlin, and Jordan discuss nine specific RFC proposals to amend the Nacha operating rules and four other RFI topics to gather industry perspectives — all geared toward reducing successful fraud incidents and improving fund recovery within the ACH network.
Payments Pros — S01E01: A Discussion with Nacha on Proposed Rulemaking Regarding Fraud
Recorded 5/31/23
Keith Barnett:
Welcome to the Payments Pros, the Payments Law Podcast, a Troutman Pepper Podcast, focusing on the highly regulated payment processing industry. My name is Keith Barnett. I'm a partner with Troutman Pepper and one of the hosts of this podcast, payment processors, money transmitters, financial institutions, lenders, and other financial technology businesses face increasing scrutiny from regulators as well as heightened consumer expectations. With this podcast, lawyers from Troutman Pepper's FinTech and payments practices will address most of the challenges confronting our clients in the legal and regulatory industries, and the issues that payment processors and others in the payments industry face. From the BSA to EFTs, FinTech to RegTech, licensure to lending, Nacha to the CFPB and payment processing to debt collecting. Our team has you covered. In our first episode, my colleague Carlin McCrory and I are joined by Jordan Bennett, Nacha Senior Director of Network Risk Management, to discuss the request for information and request for comment regarding ACH risk management. Carlin.
Carlin McCrory:
Yes, Jordan is the Senior Director of Network Risk Management for Nacha and he's been in this position for seven years. Before that, he was with the Federal Reserve Bank for 11 years as a senior business analyst and senior credit and risk analyst. Jordan has been in the financial services industry for over 20 years and we are very, very grateful to have him join us on the podcast today to discuss the nine rule proposals and four requests for information. So, with that being said, I'm going to turn it over to Jordan to give us a little overview of the proposals and RFI and dive into this.
Jordan Bennett:
Sure. Thank you. I think even before we go into the proposals, we should have a little bit of background of where they came from. Just a little setting the scene of what's going on in our industry, that all really comes out of a framework that we published back last year. It was September of 2022, and this is something that we worked on for almost a year. Now we are calling it a new risk management framework for the era of credit push fraud. What we're seeing and what we have seen in the industry is that we did a really good job on working on debit fraud. The industry has the tools they need, the industry is doing a good job, and we've really kind of closed that gap where fraudsters were coming in and debiting consumers without the permission. As we know, the old balloon theory, when you squeeze the balloon one way, it's going to pop out somewhere else.
When you stop fraudsters in one direction, they move to another. What we're seeing and what we've heard is that credit push fraud is a significant problem. What do we mean by that? These are fraud scenarios that are using push payments, ACH credits and other rails. You've got business email compromise. Vendor impersonation has been a big one. Payroll impersonation is huge. Account takeovers, fraudulent claims for benefits were huge during the pandemic. We've even seen fraudulent use of micro entries and we changed that rule last year where some companies were validating accounts with credit entries only and fraudsters figured out how to steal $60,000.28 cents at a time. So, they're always thinking we have to be thinking there as well. These rule proposals are really focused on stopping credit push fraud. We have seven credit risk management topics. Our first one is expanding commercially reasonable fraud detection.
That's beyond what we have now for just web debits. It's really expanding. It’s almost every party in the ACH network making sure that we're all doing something that should be done to stop for all within our organizations. Number two is RDFI monitoring of received credits. So, this is where the RDFI is monitoring incoming credits as they're receiving them and looking for fraud. Number three is expanding the use of return reason code, R17. Right now, the rules state that you can return an item that comes in for pretty much any reason. You just have to use the return reason code that fits best. If you don't have one that's perfect. We are changing R17, so it fits much better to returning an incoming credit that looks fraudulent. Number four is expanding the use of reversals for fraud recovery.
We want to expand the option to use a reversal from just an error, which is how it's defined now, to being able to quickly instigate a reversal to get that money before it goes may not work, but the faster we can get things done, we have a better chance of getting that money back from the criminal. Number five is an additional exemption from funds availability requirements. This lines up with Reg CC. It says, as an RDFI, you do have time to review these things that are coming in. If you think something's fraudulent, you don't have to post it immediately. Take a look. You do have to let the ODFI know, but you don't have to immediately give credit. It is lining up with Reg CC. Number six is standard company entry descriptions. If we're asking the RDFI to monitor incoming received credits, it's a lot easier if you have a standard to monitor too. Same thing is true with number seven, which is the standard use of an individual name field.
There are so many different ways that you can state an individual name that it is often difficult. We are not going down the path of mandating name matching on the ACH network. That's really not something we want to do on a batch system like the ACH network. But if other red flags are thrown and a RDFI wants to use name matching, this will make it much, much easier. Our last two proposals are around debits. The first one is the timing of the written statement of an unauthorized debit, and that was number eight. This just states that you don't actually have to post a debit to get a WSUD, you know can as a consumer notices or gets maybe an advance notice that a debit is coming in, that they can tell you and then you can take that WSUD that will improve the stress on that consumer without it having to post their account.
The second one is the RDFI must promptly return an unauthorized debit. Once you get that WSUD, it's important that you get it back to the ODFI as quickly as possible. We also have some RFI topics. We have our ACH network credit return threshold. We are not quite sure how to monitor returns for credit returns because anytime an RDFI is going to receive a credit and then is returning it, usually it's not. The fraudster is going to say, I'm a fraudster, I'm going to return this. They're always going to take the funds. So, it's really kind of hard to monitor that. We're looking for ideas of how you could monitor credit returns. The next idea is the idea of a third-party receiver and that is something akin to a third-party center but on the receipt side.
We have a number of parties acting in this role and we are thinking now is the time for definition. We're also looking at a risk-based approach to early funds availability. As you know on the ACH network, you can post funds early, there's no rule against posting a credit prior to settlement, and many banks are offering this as a benefit to their consumers. Should there be a rule around how you do this? So, we're just asking just in general, should there and if so, how will we implement that? Then our last one would be an NOC for SEC code or account type mismatch.
This is where a business SEC code, something like a CCD would then go into a consumer account and the RDFI would be able to return that and provide a NOC saying, hey, this is a consumer account. You shouldn't be sending CCDs to this account. We know that we have a lot of this going on in the ACH network and it does close confusion and more than the confusion is the problem of the right of return. Consumer SEC codes and consumer accounts have a 60-day right of return for unauthorized and corporates do not. Corporates only have that two day right of return. So, it is important that those match up. That's just a quick intro to the RFI and the RFCs. With that, let's get started.
Carlin McCrory:
Yeah, that was very helpful for background for our audience. So, the first thing I want to dive into is that there are several common questions within the nine proposals and one of those asked the respondent to tell Nacha if it's already engaging in the proposed practice, that's actually asked for four of the different proposals. Why does Nacha want to know whether the industry participant responding to the request for comment is already engaging in the proposed practice?
Jordan Bennett:
We want to know if you're engaging and if it's been successful. We think it probably has. We think that many RDFIs are already doing this because not only is it a benefit for the ODFI to get those funds back to their consumer or business customer, but it's also a benefit for that RDFI to not have a fraudster hiding at their financial institution. We think that many RDFIs are already doing it because they see it as the right thing to do to keep fraud off the network. We think that it aligns very close to the current BSA, AML requirements. So, for the most part, financial institutions are already doing some of these activities, although there may be a lack of communication between the BSA, AML areas and operations, we'd like to see a little bit more communication there.
Carlin McCrory:
That makes sense. So, a follow-up to that is, I assume that an ideal response would inform Nacha about how the industry participant is already engaging in these practices and both the pros and the cons of that practice. Is that what you all are looking for as well?
Jordan Bennett:
Yeah, we are a self-governing system. The financial institutions through Nacha really are the ones that write the rules. It's not just us. So, we want to expand things that are being successful. If you've got a successful practice that we can hear about and better improve the rule, then tell us.
Carlin McCrory:
Then in that same vein, would it also be helpful for industry participants to possibly give a cost benefit analysis of compliance, both the cost incurred for them, but also maybe how much time it took to establish the system? What do you think of that idea and how could that be helpful to you all?
Jordan Bennett:
I think the cost benefit analysis is going to be a little funny here because you're as an RDFI, you've got some cost incurred, but the losses are really going to be taking at the ODFI, right? So, you're building something to protect the network in another party, but if everybody does it, you're also benefiting yourself. Because we are self-governing, if we don't stop these losses, we're going to have other regulators coming in and regulating the network, which is not something we want to do. We think that by having effective self-governance and by stopping these fraudsters, we really are benefiting everybody.
You've got three options if you're an RDFI that has a fraudster, right? Your first one is going to be your KYC wasn't effective, you onboarded a fraudster. That's not good for you as an RDFI. The second is you have either a knowing or unknowing mule at your financial institution. Also, not good. Third is that you've got an account takeover and a fraudster is using one of your accounts, one of your consumer business accounts to take in money and move it on and potentially empty that account as well. So that's not going to be a benefit to your consumer. There's no benefit of having a fraudster use your financial institution.
Carlin McCrory:
Right. That makes complete sense. On the opposite side of my initial question, if an industry participant isn't currently engaging in the proposed activities, would Nacho want to know maybe the reasons why they've made an affirmative decision not to do some of these things? Would that help inform the rulemaking as well?
Jordan Bennett:
Absolutely. Let us know why you don't think this is helpful or why you shouldn't be a participant. We really are trying to make the rules as effective as possible and we need the industry's thoughts on that. It's a complicated process.
Carlin McCrory:
Yes, we understand the complexities involved. To wrap it up kind of on my preliminary questions, can you give some examples of helpful or not helpful reasons that a respondent could give for not currently engaging in the activity or maybe for they are engaging in the activity and some things that would be helpful for you all to see as well?
Jordan Bennett:
Sure. So, I think any example of where they've done some of the things that we're talking about and stopped a fraudster, a criminal, stopped money from getting out of their bank would be super helpful. Any time that we can see that this type of stuff is working, that's where we want to expand it. We want fraud to go elsewhere. We know that fraudsters are not going to stop. I mentioned earlier on debit, the industry does have pretty good control on debit fraud. We still have debit fraud. We're always going to have debit fraud, but we're just always looking for new ways to reduce fraud as much as possible.
Carlin McCrory:
Sure. Maybe some takeaways that I'm hearing from you or some specific examples would be really helpful to know about situational analysis possibly.
Jordan Bennett:
Yeah, absolutely. How difficult it was. If you're communicating with different silos within your bank, you know how AML, BSA groups have helped operations or vice versa or how you've reacted with other financial institutions. We have heard communication is sometimes difficult between financial institutions, although we do know that there are carve outs in the laws for fraud. You don't have to protect that fraudster when it comes to privacy.
Keith Barnett:
Jordan, I have a couple of questions. Another common question in your proposals is whether the industry participant believes that the proposal advances the risk framework in the recovery of funds. That seems to be the common theme. For example, proposal number two, you require RDFIs to establish commercially reasonable fraud detection systems that monitor their received ACH credit transactions. Then another example is you mentioned earlier is that proposal number three would allow but not require the RDFI to use the R17 return entry code if it thinks that something is fraudulent. But in my practice and what we've been seeing is we've seen from fraudulent wire transfers, for example, that the money is gone before the RDFI can even investigate the issue. It's gone off somewhere else. So, I was wondering what kinds of thoughts and insights is Nacha looking for from industry participants on the issue of whether the proposal advances, the risk, frameworks, goals of improving the recovery of funds?
Jordan Bennett:
With monitoring incoming credits, we're hoping that you're able to either use automation, you can purchase vendor supplied software, you can build something and everything doesn't have to boast immediately. We're hoping that the RFIs can catch some of this. Let's use payroll impersonation. This is a common scheme. If you've got one individual who is all of a sudden receiving five payroll deposits, that should be a red flag. Those don't necessarily need to post immediately and hopefully if that RDFI can say, oh, hold on, this does not look correct. They can then determine whether they think it's fraud or not and send those back and those consumers can be made whole.
Keith Barnett:
Actually, your response just led to my next question because you do you have a proposal number six, it will be to establish a standard description of payroll for payroll and purchase for e-commerce purchases. So, it sounds to me like you saw increased instances of payroll related fraud, hence the addition of payroll as a description. But what else was not just seeing or hearing that led to these proposals and what kind of comments will be helpful with respect to this proposal?
Jordan Bennett:
We've got those two ideas already out there, the payroll and the purchase. So, on those, we really want to know what other areas could we do for a standard company, true description, we already have a few. We've got account verify reversal, HC, claim payment and retry payment. Any time we can standardize something, especially if we're asking the RDFI to automate things and to monitor credit transactions, you can do that. But only if you have a standard.
We saw when looking through the operator data that there is an unbelievable number of different ways that payroll companies say payroll, direct deposit, direct deposit with the company name DD, all kinds of different ways. So, if we're asking the RDFI to become involved, let's make it easier for them. That's really the idea. We'd also, I think I just said a minute ago, but we really want to know other ideas, other standard descriptions that would help RDFI say, yeah, this makes sense. I can see what's happening in this account using this description. Then we can move forward and potentially expand standard company entry descriptions.
Keith Barnett:
That makes sense. I want to shift gears a little bit to proposal number seven that you talked about earlier. That will standardize the formatting for an individual name field for the consumer names. In the description of that on your website, you justified it by saying, and you said this earlier, that a standardized format may permit the RDFIs to better identify when an account is receiving entries from multiple receivers who may not be named on an account and that this activity may be indicative of a party acting as a mule in a fraud scheme.
Earlier this year, a federal district court found an RDFI liable to an originator, which is pretty much unprecedented. It was a rising out of an alleged fraud scheme in which a mule was used. The court noted that there was a lack of consistency with respect to name matching. That was a factor that the court considered. Now you made it very clear earlier. So, while we don't think that Nacha's intent is to expose RDFIs to potential liability from originators, would it also be helpful to Nacha if responses from RDFIs or industry participants analyze the liability risk and weigh those risks against the purpose of the proposed rules?
Jordan Bennett:
Sure. I think that's a fair question. These things, that court case and our rules just happen to coincide. I think there's going to be a lot more to come with that court case. I don't know what's going to happen when it's appealed, but that is independent of our rules. We are not changing any of the warranties. The ODFI still has all of those warranties. We're just asking for help. We want the RDFIs to be involved in the process and say, hey, we need to do our part to stop fraud as well, because they are often going to be in the best spot to identify these frauds.
They're going to be in a place where they can see things coming in with debit fraud. It all happened at the ODFI, with returns, with onboarding bat originators. The network could see which ODFIs were the problems. We implemented rules. If you'll remember, that happened 10, 15 years ago. That was very difficult. There were a lot of people that said, this is tough. We don't necessarily want to do it, but it worked, and the amount of debit fraud of the network has plummeted and it stayed down. This is going to be pretty hard. We understand that, but it's going to be a big benefit to the network and to consumers and businesses.
Keith Barnett:
You just mentioned it's going to be pretty hard. You have two effective dates, right? One on March 15th, 2024 for proposals 3, 5, 8, 9 and September 20th, 2024 for proposals 1, 2, 4, 6, and 7. Some participants may think that's a little bit ambitious. So, for those respondents who think that the dates are too ambitious, what facts do you need to hear from them and their responses in support of that assertion that the dates are too ambitious?
Jordan Bennett:
Sure. So, on that first date, there's no coding requirements. Those are just policy procedure changes. That should be sufficient time. There's nothing that the banks need to necessarily do on their internal systems to make those happen. That's what we think. If not, let us know. But on the other ones, there are hard coding changes. Things that have been set since companies have started many, many years or decades ago. We know that's going to be a challenge. Time and resources are going to have to be put in. Let us know if our date is not far enough out and that you're going to need more time. We want to make sure that it's implemented correctly and evenly across the network. If it can't be done, let us know. Let us know what a reasonable date would be.
Keith Barnett:
Since you already have the dates where you do want these rules to be effective, does that mean that the rules are pretty much already written or are you going to pay attention to these responses?
Jordan Bennett:
Oh no, not just have write these rules with definite feedback from the financial institutions, but we are nowhere near set. If we've got good ideas that come in, we ask for the RFCs because we care. We want to manage the rules in the best way possible. We've made a lot of changes in the past as financial institutions and individuals have made feedback available to us. When you comment and you've got a good idea, your idea helps us. So, we will absolutely change what gets voted on. We'll put that out there, and then the member banks and the payments associations would vote on the modified rule language.
Keith Barnett:
That's great to hear. For those listeners out there, remember that the date is June 16th to provide those comments. You mentioned earlier, we'll just talk briefly about this, just one last question. You mentioned that there are also RFI topics as well, and comments to those are due on June 30th and there are four topics that you talked about earlier. Can you speak generally about what Nacha's looking for with respect to the information in these areas so people can better respond and get you what you need?
Jordan Bennett:
Sure. I do want to reiterate again, we are going to listen and read every single comment that comes back and take those into account with the RFI, the request for information. These are ideas that we don't have solid proposals for yet. We don't have solid rules proposals. So, what we're looking for is guidance to how something like this would be implemented. We're not looking for you to write rules language, but give us an idea of where to go, so we know what the industry's looking for. If you're doing something successfully, have you done something you think that would help other financial institutions and should be written into the roles, then let us know there too.
Keith Barnett:
Great. Thank you. Well, Jordan, thank you for joining us today. This has been great. Thank you to our audience for listening to today's episode. Don't forget to visit our blog, consumerfinancialserviceslawmonitor.com and subscribe so you can get the latest updates. Please be sure to also subscribe to this podcast via Apple Podcast, Google Play, Stitcher, or whatever platform you use, and we look forward to you the next time. Thanks everyone.
Copyright, Troutman Pepper Hamilton Sanders LLP. These recorded materials are designed for educational purposes only. This podcast is not legal advice and does not create an attorney-client relationship. The views and opinions expressed in this podcast are solely those of the individual participants. Troutman Pepper does not make any representations or warranties, express or implied, regarding the contents of this podcast. Information on previous case results does not guarantee a similar future result. Users of this podcast may save and use the podcast only for personal or other non-commercial, educational purposes. No other use, including, without limitation, reproduction, retransmission or editing of this podcast may be made without the prior written permission of Troutman Pepper. If you have any questions, please contact us at troutman.com.