Captioner: Becca Posadas
Date: October 22, 2025
Time of event: 11:00 AM
Name of event: Nacha New Rule Changes 2026
This text, document, or file is based on live transcription. Communication Access Realtime Translation (CART), captioning, and/or live transcription are provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings. This text, document, or file is not to be distributed or used in any way that may violate copyright law.
This document may contain legally privileged and/or confidential information. If you are not the intended recipient(s), or the employee or agent responsible for delivery of this message to the intended recipient(s), you are hereby notified that any dissemination, distribution or copying of this document is strictly prohibited. If you have received this document in error, please immediately notify the sender and delete this document from your computer.
Confidential & Proprietary
JPMorgan Chase & Co.
For Internal Use Only
>> PRIYA JOHAR: Good morning, good afternoon, and good evening to everyone joining us from different parts of the globe. Welcome to the Nacha Rule Changes 2026 webinar brought to you by JPMorganChase. My name is Priya, and I'm joined today by my colleague, Eric Nulph. Together, we'll be your speakers for this session, guiding you through the upcoming changes and their impact on ACH operations.
But before we begin, I'd like to provide a brief disclaimer to ensure everyone is aligned on the scope and the intent of today's discussion. Compliance with Nacha rule changes is the responsibility of the client and not JPMC, and clients should consult with their legal and compliance representatives. Clients remain subject to and solely responsible for compliance with their obligation under applicable Nacha and other payment network rules.
With that, we'll move on to the next slide.
So the agenda for today is listed on this particular slide. Today's agenda is both comprehensive and forward‑looking. We'll begin with a high‑level overview of the 15 rule changes that were balloted in 2024, setting the stage for our discussion for today.
From there, we'll take a closer look at the four rule changes that will come into effect in 2026, exploring their potential impact and significance. So as we move through the presentation, we'll examine the key parameters and analytical approaches you can use to determine as to which rule change would be relevant for you or for your organization.
Finally, and perhaps the most important, we'll highlight essential considerations and actionable practices to help you adapt to the rapidly changing payments environment. We'll also share some of the industry's best practices for fraud monitoring throughout the payment lifecycle, equipping you with practical tools to enhance security and resilience.
So let's get started. In this slide, we are specifically talking about what significance do the rule changes carry. Before I delve deeper into the 15 rule changes, we'd first touch upon the significance of each of these rule changes.
As of March 15, 2024, Nacha, which is our governing body, Nacha's voting membership approved 15 ballots to achieve three key aspects. One, to detect fraud attempts. Basically, through these rule changes, strengthen the ability of the ACH network to detect any fraud attempt that can happen. Second is reduce fraud attempts. Take necessary steps in order to reduce the incidence of successful fraud attempt. And third and the most important, should there be a successful fraud attempt, what enhancements should be required in order to improve the recovery of funds altogether?
Next, so the next slide shows or gives the overview of three of the compliance dates, or rather three of the compliance dates out of four that were listed by Nacha. These three compliance dates are spread across 2024 and 2025 and comprises 11 of those 15 rule changes.
The first compliance date was applicable June 21st, 2024, and had six minor rule changes topic that was covered on that particular date. The second compliance date was on October 1st, 2024, and that comprised four of the risk management topics. The third compliance date, which is the most recent one, was on April 1st of this year and comprised another risk management topic. And till now, we are past 11 of those 15 rule changes implementation dates.
The next slide gives an overview of the four rule changes which will be applicable next year. Two of those rule changes would carry or entail two applicable dates. One would be March 20th of next year and the second one would be 22nd June. Both of the two dates differ primarily because of the thresholds and we'll be discussing in detail about those thresholds and applicability of the rules in the subsequent slide.
You may also find certain resources out there that would state that the applicable date would be 19th June instead of 22nd, but as of recent change, Nacha changed that date from 19th to 22nd, given that 19th is a US public holiday.
The remaining two rule changes, which is rules six and seven, is applicable on 20th March next year, and that contains only one applicable date. And we'll be discussing about those two rule changes in the subsequent slides.
The next slide talks about why is it important for you to understand and comprehend the Nacha rule changes 2026, and primarily, what are the objectives of having this webinar in the first place itself.
So one, knowing about the rule changes will help you from a compliance maintenance perspective. So staying abreast with the industry changes will help you avoid penalties and promote secure ACH transactions.
From an operational improvement standpoint, you'll be able to streamline processes and align your processes as per the updated standards, thereby reducing errors, enhancing transaction monitoring, and speed as well.
The third part is on strategic positionings. So given that you'll understand the rule changes better, you'll be able to implement some of the best practices in order to monitor your transactions. And with that, you'll be able to strengthen your reputation and build trust amongst your partners and customers.
Fourth and the most important pillar here would be financial advantages. So complying with the rule changes would help you avoid any losses due to penalties and would also help you transit secure ACH transactions, thereby saving you a lot of cost when it comes to fraudulent transactions.
So ultimately, this webinar is about empowering you with the knowledge and tools you need to navigate these changes confidently. We want to help you optimize your ACH transactions, reduce errors, enhance operational efficiency, and secure financial benefits by being informed and prepared.
By working together and staying ahead of industry best practices, we can ensure a smooth transition and continued success for all the participants throughout the ACH network.
Next slide, please. Next.
So, now as we transition into talking in detail about each of the four rule changes, this slide is speaking about the four rule changes from an overview perspective.
So, as we discussed earlier, there are four rule changes which will be applicable 2026. The first one would be fraud monitoring by originators, third‑party service providers, and originating depository financial institutions. So all of these participants would need to set risk‑based processes and procedures in place so that they are able to track transactions that are conducted under false pretenses or are unauthorized in nature.
The second rule change would be on the receive side, basically indicating Nacha's interest and proactiveness now towards the receive side of fraud monitoring. So as per the second rule change, the receiving depository financial institution would need to set up risk‑based processes in place so as to monitor credit transactions on the receive side.
The other two rule changes would be about payroll and purchase, basically adding these two nomenclature into the company entry description of certain transactions.
Next. Talking specifically about payroll, which is rule change six, standard company entry description payroll. So the use of the term "PAYROLL" should take place in such transactions which are initiated by the originator with the intent of sending or paying money in terms of salary, wages, payroll to the receiver.
Whenever there is an intent of paying wages and the transmitting form is through the ACH, with the SEC code PPD credit, the word "PAYROLL" needs to be added to the company entry description.
Now, Nacha has mandated a way in which the word "PAYROLL" needs to be added. It should be left aligned. The remaining three spaces of the company entry description can be used as per the requirement of the originator. And more details about how the usage should be is provided on the Nacha website under their FAQ section.
Through this rule change, Nacha has not obligated that an ODFI needs to verify the presence or accuracy of the word "PAYROLL" as a description of purpose or employment status of the receiver. So it is completely at the prerogative of the originator to really understand the usage, the intent of the payment, and add the word "PAYROLL" accordingly.
The next rule change is similar to "PAYROLL", which is "PURCHASE".
Can we move on to the next slide?
So this particular rule change is applicable for all instances where an e‑commerce purchase, which is a web debit SEC code entry authorized by a consumer‑receiver for the online purchase of goods happened, including recurring purchases first authorized online. So in such instances, the word "PURCHASE" would need to be added to the company entry description.
Here again, there is a standard practice that Nacha has mandated to all the participants of the network. The word "PURCHASE" should be appearing in the company entry description. It should be left aligned. The remaining two spaces can be used as per the convenience of the originator.
Here again, the ODFI has no obligation to verify the presence and accuracy of the word "PURCHASE" as a description of purpose. For more details, again, you may refer to the Nacha website and can search through the FAQ section to understand the exact applicability of the word "PURCHASE".
Now, in both those instances, in both these two rule changes, we as financial partners, we as your financial partners or your financial institution can help with regression testing. So, whenever you have, you know, sort of built an infrastructure or made that technical development where the word "PAYROLL" and "PURCHASE" can appear on the intended transactions, you can send sample files to us for testing. We can check how the word is appearing in the company entry description and how it will be transmitted to the ACH network.
So we are available at your disposal for whatever regression testing that you'd be interested in doing. And for that, you may also feel free to reach out to your client service representative or your relationship banker to avail of this service.
We'll move on to the next slide, which basically talks about fraud monitoring from an originations perspective, and we'll also discuss on the receive side along with the transaction analysis as to which rule change would be applicable to you.
So more on that by Eric. So Eric, over to you.
>> ERIC NULPH: Thank you, Priya. And thank you, everyone, for joining this very important information sharing session.
The next two rules that I'm going to describe really encompass almost every participant in the ACH network. So more than likely, everyone that's listening to this call is going to be affected by the rule number one that you're seeing on your screen now.
And before I get into the details of these two rules, I want to talk about a new term that Nacha is introducing into the rules language. And that language or the term is called "false pretenses".
And what they're trying to do with the term "false pretenses" is identify when a payment may be induced by a person who's misrepresenting their identity. They're misrepresenting their association or authority to authorize transactions against a certain account. They are misrepresenting that they actually have permission if you were, let's say, a CFO at a company and somebody misrepresents themselves as that person. That is inducing an ACH entry under false pretenses.
So when we, kind of, dive into these rules, and we'll specifically start with rule number one, every single originator, every single third‑party service provider or third‑party sender, every single ODFI in the network, and for rule two, every RDFI in the ACH network are affected by these rules. So as we go through them, keep in mind how the rule may apply to your specific circumstance.
So as we dive into rule number one, and it talks about origination, and really, all debits and credits are going to be in scope for this specific rule, right? And what they're trying to do is tell you to establish and implement a risk‑based process or procedure relevant to your role in the authorization and processing of a transaction. And we'll talk about that a little bit more here in a minute. And it's reasonably intended to identify entries that are suspected as being unauthorized or unauthorized under the new term False Pretenses.
So when we look at that, they're not really asking you to check each transaction as you originate or as you process. They're asking you to create a sensible procedure to be able to detect and prevent invalid entries from being created in the first place. So they're not asking you to review each transaction individually. They're not necessarily asking you to detect entries before they're processed. It could be a process where you're monitoring activity, you're monitoring trends, you're monitoring expected outcomes, and you're detecting that you have suspect entries, and then you're actioning those entries.
And the reason they wrote the rule this way is because it needs to apply to all participants. It needs to apply to an originator who only sends 10 payroll credits a week. It needs to apply to maybe an e‑commerce platform that sends 100 million transactions a week, right? So it's really allowing the originators in each participant to, based on their role, to decide what is best for them.
So let's talk about the participants themselves. So if you're an originator, who is the originator? It is the party that has the relationship with the receiver of the entry that's being created, right? Those are the people that are best positioned to understand and authenticate that the party authorizing the transaction and providing the financial information related to it are the actual intended recipient.
So what do these cover? It kind of covers just standard disbursements: Payrolls, pensions, maybe retirement payouts, maybe refunds of, you know, maybe a return on Amazon or something, and you're getting a refund to your bank account. It covers vendor payments.
And it doesn't actually have to be a corporate. It could be a government agency, who's maybe processing tax payments or tax refunds. And then it also extends on the debit side to collections. So now you're collecting for a bill payment. You're collecting for a debt to be settled.
And in all these cases, if we go back to the definition of False Pretenses and what these suspect transactions are, we're trying to make sure that we can identify and detect things like account takeover, like business email compromise, like vendor impersonations.
So it's very common things where a bad actor has come in and is trying to redirect a payment. So I'm trying to redirect a payroll or a vendor payment to an account that it's not intended to go to really. I'm trying to satisfy a debt by debiting an account that isn't mine or I'm not authorized to debit. And these things make perfect sense from an originator perspective, right?
So now the next participant would be maybe a third‑party service provider. And what they're doing is maybe they're performing functions for the originator. Maybe they're creating payments. Maybe they're sending payments on behalf of that originator.
Another flavor of that is a third‑party sender, and the third‑party sender maintains a relationship with the ODFI to be responsible for settling payments for their underlying clients.
Third‑party senders have an entire chapter in the Nacha rule book related to their obligations for sound risk management practices and different things related to their customers.
And then the last participant would be the ODFI. And the ODFI sends entries into the network on behalf of a third‑party sender or an originator.
And why are they in a good position potentially to identify bad transactions? They have information that they've accumulated over time on bad actors. They have sophisticated software that can detect patterns or first‑time beneficiaries where activity might be abnormal.
They have returned item monitoring, which can detect when, potentially, there's a large number of unauthorized entries being claimed and disputed, or invalid account numbers being sent back, which would be indicative of somebody just making up account numbers for bill pays and certain things like that.
So those are kind of a drill down into who these different actors are. And from an applicability standpoint, the first implementation date is going to be March 20th of 2026. And that applies to the participants who have volumes of 6 million items or greater in 2023.
And then everybody else comes into scope by June of 2026. So that's why everybody is affected by this rule.
And what you want to do, again, is apply a risk‑based approach. What makes sense for me? How does my company or my originator manage acquiring financial institution and account information? How do they manage modifying it? How do they manage validating that account numbers are valid or that users are authenticated?
And then you would apply this risk‑based process or procedure to be able to detect that activity.
So your first step is really to document what it is you do today. Your second step is to assess whether or not that process will reasonably detect fraudulent behaviors. Then you need to modify that process if your situation has changed or if it doesn't really meet a risk‑based control. And then finally, you need to establish an annual review period to review those processes annually.
So if you're doing an annual Nacha rules compliance audit, maybe it sits in there. Maybe it sits with the compliance group. But the important piece is to continually go back and revisit those controls and those processes as times change, as fraudster capabilities change over time. Because what we see today is nothing like what we saw 10 years ago.
So, if we move on to the RDFI ACH credit rule. Next slide, please?
This applies only to incoming credits to a RDFI, which is the bank receiving the entry and posting it to an account. Now, I'll say that most banks have some sort of process. And it's normally something that they're reviewing items after they've posted.
All banks have anti‑money laundering processes. They have financial crimes obligations. So many banks already have something in the hopper for this.
But again, the same theory applies. Apply a risk‑based process that's relevant to your role ‑‑ you're the RDFI ‑‑ and does it reasonably detect bad activity?
Now, ideally, I think, you want to detect activity prior to posting, especially in the event of a credit. If it's a credit and it's posted and it's intentional fraud that's performed under false pretenses, your recoverability of those funds is much less if you allow it to post than if you prevent it from posting in the first place.
Again, same rules apply. Document it, assess it, change it if you need to, and then establish an annual review process.
So the other advantage an RDFI has in these cases is they have information on bad actors. They're very intimately aware of what normal activity under an account is. They're very aware, through know your customer guidelines, what is expected on an account.
So they know how long the account's been open. They know what to expect. And they're in a very good position to be able to detect anomalous activity.
So if you go on to the next slide. Next one. One more. Okay.
So, again, how do you apply it? Looking specifically at Rule 1, which is originators, third‑party processors, third‑party senders, and ODFIs, everybody is impacted. So, again, you'd want to assess when is my implementation date and what activities do I have to do to be able to get there?
If we look at the second use case that Priya went into detail with, which is payroll, I don't think we need to say too much there because she did a very good job in indicating payroll.
We have been asked questions. Does commission ‑‑ is commission pay payroll? And the answer is yes. Commission pay is related to compensation. And any entry that's PPD entry, which is consumer that's related to compensation, would need the keyword "PAYROLL".
And then if we look at the purchase rule, again, it's for debit initiations, primarily web debits, and those would need to use the keyword "PURCHASE".
And I think as time goes on, Nacha is going to do more of this codifying of transactions to be able to identify specific activity in the network. So don't be surprised if, from a risk management and operations perspective, they come out with more of these.
Relative to web debits on the purchase side, I'll add that there's an existing rule that's out there. So any debit originator of web debits actually has a more stringent requirement for fraud detection than is set forth in these new rules. Right.
If you're a web debit originator, you are to have a commercially reasonable fraud detection system. You are to have an account validation system. You are to have are to have bank ID validation processes. And actually, those are much more stringent than what's being called for here, which is a risk‑based detection system.
So if you're already doing web debits, you should probably take this opportunity to go look at those commercially reasonable fraud detection processes. Make sure that they're up to snuff as you're looking at applying the keyword "PURCHASE".
So hopefully, you found that information useful. And I'll pass it back to you, Priya.
>> PRIYA JOHAR: Great. Thank you so much, Eric. Can we move on to the next slide, please?
So taking cues from what Eric mentioned in terms of certain points to consider, given the dynamic fraud landscape or the payment landscape that we have, we need to ‑‑ it is important that every organization and every business conduct a compliance review, have regular processes set in place so that they are able to review those compliance processes.
They are able to enhance their fraud monitoring or implement the fraud monitoring in order to stay in compliance with some of the rule changes. And also are able to change or adjust their strategies to the dynamic world of ever‑changing fraud landscape that's there.
But apart from that, there are a couple of points also to consider. One is education and training. So that's an important point that you'd need to build as an organization. You need to foster a culture of compliance by educating and training each and every employee about the Nacha rule changes, and not just that, about Nacha rules in general as well.
Now, what will happen is that once people start understanding the Nacha rules, the Nacha rule changes, its applicability, the reason behind it, there will be easier or faster adaptability to these rule changes. And you, as an organization collectively, will be able to achieve compliance faster and more seamlessly.
The last point to consider, and the most important of them all, is seek legal advice. So consulting with your legal and compliance experts is very important. It's imperative to not just do it on an ad hoc basis but to actually embed that culture on a day‑to‑day basis so that you're able to gain insights and advice on Nacha rules and its applicability so that you're able to navigate the changes and the rules that are currently there.
Next slide, please.
So this slide talks about some of the best practices for fraud monitoring, for ACH monitoring as a whole. So if you are considering the entire payment life cycle, there are three key touch points that really are very meaningful and impactful and can lead to some key risk areas if not taken care of properly. So one is identity and onboarding, which is basically the starting or the genesis of the entire payment life cycle.
Some of the key risk areas at the start stage or at the stage of onboarding is you can end up onboarding fraudulent entities, you can end up onboarding synthetic identities to your organization or to your account that can lead to account takeovers and other such issues.
The blue box indicates the best practices and we'll come back to that in a while.
The second touchpoint in the payment lifecycle is change management itself. By change management, we mean every time there is a change in, probably, the name of the already‑existing entity that's listed or, say, the account that's listed or if there is a change in phone number, a change in account details, etc.
All of that needs to be taken care of carefully because such instances or such changes can actually lead to account takeovers. It can lead to impersonation fraud and it can lead to a lot more issues if not, you know, taken care of very specifically through certain best practices.
The third and the most important part in the entire payment lifecycle is payment and disbursement itself. So there are certain key risk areas there. One is ACH credit fraud can take place if the beneficiary accounts are not identified, as Eric highlighted earlier.
There can be instances of unauthorized disbursements. There can be instances of billing fraud, etc.
So starting with identity and onboarding, some of the best practices are, first, set up multi‑layered identity verification. So you can leverage some of the real‑time API integrations in order to verify name, address, phone number, email, and all other details of the account getting onboarded. That can be done against, say, government databases, sanction and watchlist screening, etc. So all of that can be done against some database, some validated database, so that you can ensure 100% accuracy there.
You can also leverage device intelligence and geolocation checks that can be available at your disposal while you are building multi‑layered identity verification as a process to your identity and onboarding of the payment lifecycle.
The second part is ‑‑ or the second example is behavioral and predictive analytics. So there is a lot of data available at your disposal all the time, given that we live in a world full of data. So it is important, it is imperative that you as an organization start leveraging that data and are able to build a robust process so that you're able to detect patterns of suspicious behavior and synthetic identities using your historical data that could be available in your data lake or in some warehouse, etc.
The third part is account ownership and payment information matching. So basically, under this best practice, what really happens is that you'd be integrating your account onboarding by deploying bank account verification processes to confirm that the account details really match with the entity's legal name that is getting listed at the time of onboarding.
You can also use cross‑check payment method where you're actually checking information with known high‑risk accounts of flagged entities against some verified database. Now, all the best practices that we are mentioning are something that can be availed of either through third‑party providers. It can also be built internally. So, we have a lot of clients who have chosen to build all of these processes internally as well, given their business appetite, their risk appetite, etc. So, it's a call that you'd need to take.
Third, you can also choose to, you know, talk to your financial institution to check if they have any product available that can help you, you know, set processes, fraud monitoring processes in place at each of the stages of the payment lifecycle.
With that, I'll move on to the second part of the payment lifecycle, which is change management. Some of the best practices that you can consider is multi‑factor authentication. Basically here, you require step up authentication to be in place or, you know, you're setting up secondary communication channel through SMS, phone, email for really high‑risk changes. So whenever you feel that, you know, there are certain high‑risk changes that are happening in terms of, say, changing the threshold of the transactions being sent or changing the name of the entity that is already onboarded since a while. It is important that you set up step‑up authentication in the form of, say, OTPs, in the form of biometric verification, knowledge questions, etc.
Another best practice that you can consider is setting alerts for unusual activities. So basically, under this practice, whenever you feel that a particular account is being changed very often recently ‑‑ account details is being changed very often recently and there is a pattern to it ‑‑ you may choose that alert to be sent across to all the impacted parties and stakeholders.
So, such tools are also, again, available at your disposal in the market. You can explore those tools by talking to your FIs, and you may also choose to build it in‑house, given the risk appetite that you'd want to trade on.
The third and the most important part of the entire payment lifecycle is payments, and some of the best practices there is, one, real‑time account status and risk screening. So basically, integrating bank account validation APIs to check whether the beneficiary account is open, is active, in good standing, or if there are any past fraudulent activity that may have taken place on the receiver side.
Second is account ownership and verification, wherein you are leveraging or using risk‑based scoring for new pays, especially for large‑value ACH transactions, so that you're able to detect any of such beneficiaries, fraudulent beneficiaries beforehand. Third, and recently the most common that we have noticed is transaction limit and velocity monitoring.
So basically there are a lot of clients who are setting thresholds to the transactions that can be transmitted to the receiver's account. They are also setting limits to the frequency or the number of transactions that can be sent across.
And all of that can be availed of by using a particular tool, by either developing it in‑house, etc. So these are some of the best practices that can help you understand and can help you navigate some of the risk‑based processes across the payment lifecycle, depending on the business financial standing that you may be having, depending on your legal and compliance obligations, etc.
With that, we'll move on to the next slide, please.
So we at J.P. Morgan provide a couple of products under our trust and safety umbrella and that comprises account confidence score and identity account validation.
Now so to note, just a disclaimer here, these are certain products which are available at your disposal for you to build fraud monitoring processes. It does not ensure that you'll be in compliance, so you'll still need to consult with your legal and compliance teams and understand your risk appetite in order to ensure that, you know, availing of these products may or may not lead to compliance of the rule changes as mentioned earlier.
Now, what is account confidence score? So, account confidence score is basically an AI‑based machine learning score that actually generates or indicates the probability that a beneficiary account is anomalous or fraudulent.
And how does it really work? So, this particular product that we have developed is a derivation of in‑house fraud screening model, which is an AI/ML model that we have built that helps translate our output into a numerical indicator. Now, that output can help you or allow you to evaluate the likelihood of fraud on the beneficiary account.
So, when can you really use this particular product? So, we spoke about the payment lifecycle in the previous slide. This product usually fits the bill at the time of onboarding, at the time of registration of an account or of an entity in your organization and can also help you in advance of any payment instruction. So that's account confidence score for you.
The second product that we have is identity and account validation. Basically, there are two sub‑products under it: AVS and EVS.
AVS is Account Validation Service that provides the ability to validate the status and ownership of an account. While EVS, which is Entity Verification Service, provides verification of individuals of business data from trusted data sources and third‑party regulatory vendor.
So when can you use this product? Again, from a payment lifecycle perspective, it can help you at the point of onboarding or registration or even before initiating a payment instruction.
Now, both these products that I spoke about was, I mean, my description was very brief. If you'd want to have a demo, if you'd want to go through, get a walkthrough of the product, understand these more in details, you can reach out to your client relationship manager at J.P. Morgan, and they'll be more than happy to walk you through both the products and help you understand its utility in your business environment.
Before I conclude, I'll once pass it over to Eric, and then I'll provide my concluding remarks. Eric, over to you.
>> ERIC NULPH: Sure. So, I took a peek at the Q&A queue. So, while we don't have time to answer all the questions that are in there, there are certainly some interesting ones. One was, what do we do if we don't send Nacha‑formatted payments and we send ISO‑formatted payments?
And that's a great question because many banks and many originators use different types of transaction initiation vehicles. You can use ISO pain.001 or pain.008 for credits and debits.
You might be using an API, which typically they're kind of smaller versions of ISO payments.
You could be using EDIX12. While not very common, you could be using SWIFT formatted entries to send to your bank. I don't think that that's very common for J.P. Morgan clients. But what you do in those cases is you would work with your specific channel originator because those payments all end up in ACH format eventually.
So the people that support your specific initiation channel are in the best position to tell you, for example, how do I accomplish the requirement for payroll and purchase? And it could be a combination of, if you only do a single type of entry, maybe they're applying a default value and maybe that needs to be updated. If it's a dynamic value ISO, typically, those are the piece of data for payroll and purchase travels and something called category purchase proprietary.
So go speak with the the the group that supports your channel. If they have any additional questions, they'll come to us, their ACH expert teams. And hopefully, you would have a nice, easy path to get those changes made relative to would we be able to have a roadmap or a checklist really beyond what we've shared today, we can't tell you based on your specific circumstance what you need to review when you're assessing your risk‑based analysis.
We would not be able to tell you what changes we need to make. And as Priya mentioned at the beginning, you know, we may have tools and we may have expert advice to help you achieve compliance, but we cannot rubber stamp that whatever you have come up with is compliant to the rule. That's really up to your own legal and compliance areas within your own institutions.
And I think the only other question I saw out there that was repeated, Priya, was whether or not this presentation will be available. Will it be just a recording? Is it available in hard copy? And I'll defer to you on that.
>> PRIYA JOHAR: Yeah. Thank you so much, Eric. So, well, yes, the deck and the recording will be available to you at the start of October. We'll be sharing it with our client service representatives so you can get in touch with them, get the recording, get the deck and make use of the resources.
We'll also be uploading these two resources on our client resource center under the Nacha rules section. So you'll be able to extract both of them from there as well.
Apart from that, we'll be also sending out emails to the same email list and you'll get the link to the recording and to this deck over there as well.
So all of the all of these three channels will be at your disposal so that you are able to get hold of the two resources.
We've also seen one question talking specifically about whether the word "PURCHASE" indicates or is indicative only to goods. The answer is yes. Nacha has mandated that the word "PURCHASE" would be applicable to goods only and not to services. So, things like bill payment, et cetera, will not be included in that particular rule change scope.
With that, thank you all for attending today's Nacha Rule Changes 2026 webinar. We really appreciate your time and attention as we discussed the upcoming Nacha updates, their impact on ACH, and best practices for transaction monitoring and fraud prevention.
So as we move forward, staying informed and proactive will be key to maintaining operational excellence and safeguarding your organization against emerging risks. We encourage you to review your current processes, engage with your compliance teams, and leverage the resources and tools available to you.
If you have any further questions or need additional support, please don't hesitate to reach out to us or your JPMorganChase representative. We are here to help you navigate these changes and ensure a smooth transition.
Thank you once again for joining us and we wish you continued success in your ACH transactions. Have a great day.