<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:georss="http://www.georss.org/georss" xmlns:geo="http://www.w3.org/2003/01/geo/wgs84_pos#" xmlns:media="http://search.yahoo.com/mrss/"
		>
<channel>
	<title>Comments on: About Everything ACH</title>
	<atom:link href="http://ach-consulting.com/about/feed/" rel="self" type="application/rss+xml" />
	<link>http://ach-consulting.com</link>
	<description>De-mystifying the Automated Clearing House</description>
	<lastBuildDate>Tue, 03 Jan 2012 20:19:00 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.com/</generator>
	<item>
		<title>By: achguy</title>
		<link>http://ach-consulting.com/about/#comment-3266</link>
		<dc:creator><![CDATA[achguy]]></dc:creator>
		<pubDate>Tue, 03 Jan 2012 20:19:00 +0000</pubDate>
		<guid isPermaLink="false">#comment-3266</guid>
		<description><![CDATA[Good afternoon Lynda,

For Stop Payment transactions, the item to which the Stop Pay Order relates, should not be posting first.  However, it may be in a status that called Soft Post or Memo Post...this means that the transaction has been received and is in line to be posted to your account, but has to wait for normal processing.  Once it has been returned, you should not see anything of the transaction on your account.

That being said, I would recommend checking online after regular processing has occurred and then if it still isn&#039;t right, contacting your bank.  Unfortunately, it seems that just about every bank and credit union has their own way of doing things internally and I cannot say for sure what your bank&#039;s policy/procedure might be.

I am hopeful that you&#039;ll see what you expected to see after processing has taken place.

I wish you luck,
ACHGuy]]></description>
		<content:encoded><![CDATA[<p>Good afternoon Lynda,</p>
<p>For Stop Payment transactions, the item to which the Stop Pay Order relates, should not be posting first.  However, it may be in a status that called Soft Post or Memo Post&#8230;this means that the transaction has been received and is in line to be posted to your account, but has to wait for normal processing.  Once it has been returned, you should not see anything of the transaction on your account.</p>
<p>That being said, I would recommend checking online after regular processing has occurred and then if it still isn&#8217;t right, contacting your bank.  Unfortunately, it seems that just about every bank and credit union has their own way of doing things internally and I cannot say for sure what your bank&#8217;s policy/procedure might be.</p>
<p>I am hopeful that you&#8217;ll see what you expected to see after processing has taken place.</p>
<p>I wish you luck,<br />
ACHGuy</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Lynda Spencer</title>
		<link>http://ach-consulting.com/about/#comment-3244</link>
		<dc:creator><![CDATA[Lynda Spencer]]></dc:creator>
		<pubDate>Sun, 01 Jan 2012 01:51:44 +0000</pubDate>
		<guid isPermaLink="false">#comment-3244</guid>
		<description><![CDATA[I stopped payment on an ACH debit and the bank told me et was all done.   However, when I logged on to my account, it looks like it is going through.should it be blocked right away or will it show that it is pending and then be denied by the bank?]]></description>
		<content:encoded><![CDATA[<p>I stopped payment on an ACH debit and the bank told me et was all done.   However, when I logged on to my account, it looks like it is going through.should it be blocked right away or will it show that it is pending and then be denied by the bank?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: achguy</title>
		<link>http://ach-consulting.com/about/#comment-2896</link>
		<dc:creator><![CDATA[achguy]]></dc:creator>
		<pubDate>Mon, 05 Dec 2011 21:45:01 +0000</pubDate>
		<guid isPermaLink="false">#comment-2896</guid>
		<description><![CDATA[Hey David,

Welcome to my blog.  Glad to hear you like it.

I&#039;m not completely clear whether you are referring to TEL transactions (wherein the authorization to initiate an ACH transaction is acquired over the telephone) or a Check-by-Phone situation where persmission to pay is given over the phone which results in a physical check being printed and presented for payment (signature line would read something to the effect of &quot;Signature on File&quot;, so I&#039;ll address both.

Let&#039;s talk about Check-by-Phone first.  Check-by-Phone falls under Check Law (Check out: http://www.sheshunoff.com/products/Brady-on-Bank-Checks%3A-The-Law-of-Bank-Checks.html).  Check law allows for these types of Remotely Created Checks/Drafts or RCCs/RCDs.  I&#039;m not a check law expert nor a lawyer, heck I don&#039;t even play one on the Internet, but I do know 2 things:  1) RCCs allow for use of &quot;Signature on File&quot; or some such text on the signature line - meaning no Account Holder signature required and 2) I don&#039;t like these types of transactions.  They tend to be prone to fraud.

On the TEL front, still no signature required.  As we know, every ACH transaction requires a signed or similarly authenticated authorization.  TEL falls under the similarly authenticated part.  During your telephone process, you should be authenicating the identity of the customer and either recording or sending a notice of the transaction (for one-time/single transactions) or recording the exchange for recurring TEL transactions.  Check out:  Page OR 19 - Subsection 2.5.15 Specific Provisions for TEL Entries or for a bigger picture and full details on TEL, Chapter 47 (Page OG 205) in the 2011 NACHA Operating Rules and Guidelines.  And of course, don&#039;t forget the new rules for Recurring TEL on page ORxlviii - in the Supplement #2.

With all that being said, here&#039;s my bottom line:  No signature required.  None.  

I hope that helps,
ACHGuy]]></description>
		<content:encoded><![CDATA[<p>Hey David,</p>
<p>Welcome to my blog.  Glad to hear you like it.</p>
<p>I&#8217;m not completely clear whether you are referring to TEL transactions (wherein the authorization to initiate an ACH transaction is acquired over the telephone) or a Check-by-Phone situation where persmission to pay is given over the phone which results in a physical check being printed and presented for payment (signature line would read something to the effect of &#8220;Signature on File&#8221;, so I&#8217;ll address both.</p>
<p>Let&#8217;s talk about Check-by-Phone first.  Check-by-Phone falls under Check Law (Check out: <a href="http://www.sheshunoff.com/products/Brady-on-Bank-Checks%3A-The-Law-of-Bank-Checks.html" rel="nofollow">http://www.sheshunoff.com/products/Brady-on-Bank-Checks%3A-The-Law-of-Bank-Checks.html</a>).  Check law allows for these types of Remotely Created Checks/Drafts or RCCs/RCDs.  I&#8217;m not a check law expert nor a lawyer, heck I don&#8217;t even play one on the Internet, but I do know 2 things:  1) RCCs allow for use of &#8220;Signature on File&#8221; or some such text on the signature line &#8211; meaning no Account Holder signature required and 2) I don&#8217;t like these types of transactions.  They tend to be prone to fraud.</p>
<p>On the TEL front, still no signature required.  As we know, every ACH transaction requires a signed or similarly authenticated authorization.  TEL falls under the similarly authenticated part.  During your telephone process, you should be authenicating the identity of the customer and either recording or sending a notice of the transaction (for one-time/single transactions) or recording the exchange for recurring TEL transactions.  Check out:  Page OR 19 &#8211; Subsection 2.5.15 Specific Provisions for TEL Entries or for a bigger picture and full details on TEL, Chapter 47 (Page OG 205) in the 2011 NACHA Operating Rules and Guidelines.  And of course, don&#8217;t forget the new rules for Recurring TEL on page ORxlviii &#8211; in the Supplement #2.</p>
<p>With all that being said, here&#8217;s my bottom line:  No signature required.  None.  </p>
<p>I hope that helps,<br />
ACHGuy</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: David</title>
		<link>http://ach-consulting.com/about/#comment-2895</link>
		<dc:creator><![CDATA[David]]></dc:creator>
		<pubDate>Mon, 05 Dec 2011 20:17:02 +0000</pubDate>
		<guid isPermaLink="false">#comment-2895</guid>
		<description><![CDATA[I am very glad I found this blog! I work at credit union and as of yesterday we would take a check over the phone with no signature required as of today we are now required to fax the ACH to our customer and have them sign it and fax it back… our controller think she found something in the NACHA rules and regs that has lead her to believe we are required to get the signature.  I have work at other banks and a signature has never been required for an ACH.  What are your thoughts? Do we need a signature? If you are able could you let me know what section of the NACHA Operating Rules &amp; Guidelines that would state a signature is not required? 

Great info on this site and if you can answer this one for me you will be my new Hero!]]></description>
		<content:encoded><![CDATA[<p>I am very glad I found this blog! I work at credit union and as of yesterday we would take a check over the phone with no signature required as of today we are now required to fax the ACH to our customer and have them sign it and fax it back… our controller think she found something in the NACHA rules and regs that has lead her to believe we are required to get the signature.  I have work at other banks and a signature has never been required for an ACH.  What are your thoughts? Do we need a signature? If you are able could you let me know what section of the NACHA Operating Rules &amp; Guidelines that would state a signature is not required? </p>
<p>Great info on this site and if you can answer this one for me you will be my new Hero!</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: achguy</title>
		<link>http://ach-consulting.com/about/#comment-2624</link>
		<dc:creator><![CDATA[achguy]]></dc:creator>
		<pubDate>Thu, 27 Oct 2011 19:10:23 +0000</pubDate>
		<guid isPermaLink="false">#comment-2624</guid>
		<description><![CDATA[Good afternoon Wendy,

Thanks and welcome to my blog, I&#039;m glad you like.  

It sounds like you are going to end up processing all transactions through 1 ODFI, vs. maintaining relationships with 2 ODFIs.  That is the smart thing to do.  So, then the question, do you need to notify the ODFI?  The short answer is yes.  But let me explain a little.

You don&#039;t specify which ODFI you want to notify, so let me tackle it from both sides:

You will need to notify the surviving ODFI as you may run into transaction limits with them.  You want to make sure they are aware that you will be processing X number of additional transactions each month and that the value of those transactions will grow too.  That ODFI may want to review your account with them (for underwriting/risk purposes) and just make sure that all is OK and that they can comfortably adjust your limits.  The last thing you want is to run up against your limits when you try to process all transactions for the first time.

You will need to notify the ODFI (the one that&#039;s going away) as you will want to be sure to close out that account (see the agreement on how to do that).  Also, they may have a reserve on file, they may want you to maintain funds on account for so many days (to allow for returns, etc., this is a risk consideration), they may offer you a great deal to process with them.  There are a number of reasons.

Some additional advice, you will want to make sure (just in case) that you can access all the authorizations from the other company, should an RDFI requests one and you will want to make sure that you notify  your new customers of the new name they should expect to see on their statement.  Inevitably, some will see a different name and have no idea their insurance company changed names.  Expect some amount of returns (that&#039;s also another reason to talk with the surviving ODFI - make them aware of additional volume and possible returns even if a spike is temporary).

I hope this helps,
ACHGuy]]></description>
		<content:encoded><![CDATA[<p>Good afternoon Wendy,</p>
<p>Thanks and welcome to my blog, I&#8217;m glad you like.  </p>
<p>It sounds like you are going to end up processing all transactions through 1 ODFI, vs. maintaining relationships with 2 ODFIs.  That is the smart thing to do.  So, then the question, do you need to notify the ODFI?  The short answer is yes.  But let me explain a little.</p>
<p>You don&#8217;t specify which ODFI you want to notify, so let me tackle it from both sides:</p>
<p>You will need to notify the surviving ODFI as you may run into transaction limits with them.  You want to make sure they are aware that you will be processing X number of additional transactions each month and that the value of those transactions will grow too.  That ODFI may want to review your account with them (for underwriting/risk purposes) and just make sure that all is OK and that they can comfortably adjust your limits.  The last thing you want is to run up against your limits when you try to process all transactions for the first time.</p>
<p>You will need to notify the ODFI (the one that&#8217;s going away) as you will want to be sure to close out that account (see the agreement on how to do that).  Also, they may have a reserve on file, they may want you to maintain funds on account for so many days (to allow for returns, etc., this is a risk consideration), they may offer you a great deal to process with them.  There are a number of reasons.</p>
<p>Some additional advice, you will want to make sure (just in case) that you can access all the authorizations from the other company, should an RDFI requests one and you will want to make sure that you notify  your new customers of the new name they should expect to see on their statement.  Inevitably, some will see a different name and have no idea their insurance company changed names.  Expect some amount of returns (that&#8217;s also another reason to talk with the surviving ODFI &#8211; make them aware of additional volume and possible returns even if a spike is temporary).</p>
<p>I hope this helps,<br />
ACHGuy</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Wendy Streeter</title>
		<link>http://ach-consulting.com/about/#comment-2616</link>
		<dc:creator><![CDATA[Wendy Streeter]]></dc:creator>
		<pubDate>Thu, 27 Oct 2011 01:00:43 +0000</pubDate>
		<guid isPermaLink="false">#comment-2616</guid>
		<description><![CDATA[I found your blog tonight and I find it to be the most wonderful place to get real answers.  With that being said, I have a question for you.  We acquired a company in 2007 and they have been processing the have been responsible for their ACH Web transactions with their current bank.  We are currently in the midst of creating operating efficiencies and eliminating one of two billing systems.  We are an insurance company and will be taking over their WEB transactions but have a relationship with a different bank.  Is there any need to notify them of the new ODFI?]]></description>
		<content:encoded><![CDATA[<p>I found your blog tonight and I find it to be the most wonderful place to get real answers.  With that being said, I have a question for you.  We acquired a company in 2007 and they have been processing the have been responsible for their ACH Web transactions with their current bank.  We are currently in the midst of creating operating efficiencies and eliminating one of two billing systems.  We are an insurance company and will be taking over their WEB transactions but have a relationship with a different bank.  Is there any need to notify them of the new ODFI?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: achguy</title>
		<link>http://ach-consulting.com/about/#comment-2181</link>
		<dc:creator><![CDATA[achguy]]></dc:creator>
		<pubDate>Wed, 24 Aug 2011 14:56:03 +0000</pubDate>
		<guid isPermaLink="false">#comment-2181</guid>
		<description><![CDATA[Good morning Jake,

Thanks for your question.  Typically, an authorization is with the business, vs. the business owner and so if a business is sold, the authorization should continue without issue.  For example, if I have an authorization with my gym...we&#039;ll call it Jay&#039;s Gym...and Jay (the owner) sells the business to Jacob, it doesn&#039;t matter as far as my authorization is concerned.  My authorization is with Jay&#039;s Gym (which still exists), not with Jay.  That being said, this is assuming the authorization shows the Originator as Jay&#039;s Gym and not Jay (the individual).

Now, if the sale is to a business that is planning to absorb the 1st business and Jay&#039;s Gym would no longer exist, that would be a different issue.  There are 2 different schools of thought here:  1)  As long as the members are notified of the name change in writing, the existing authorization should be able to continue without issue - at least temporarily.  It would be in the best interest of the busiess to get new authorizations as the existing ones expire or come up for renewal.  2)  The other school of thought is that all new authorizations should be captured before any transactions are processed.  I disagree with this argument.  I think it places an uneccessary hardship on the business.

While I am not an attorney, and I&#039;m sure you could find one to disagree with me, my position is based on experience in the industry.  I have seen this exact same thing happen a number of times and in nearly every case, new authorizations were acquired as existing ones expired or came up for renewal.  Those that went the &#039;all new authorizations now&#039; route were small in number.

I&#039;m sure this is not exactly the answer you wanted, but ultimately, the decision is yours.  If you are still unsure what to do, then I would recommend seeking the assistance of your legal counsel.

I hope that helps,
ACHGuy]]></description>
		<content:encoded><![CDATA[<p>Good morning Jake,</p>
<p>Thanks for your question.  Typically, an authorization is with the business, vs. the business owner and so if a business is sold, the authorization should continue without issue.  For example, if I have an authorization with my gym&#8230;we&#8217;ll call it Jay&#8217;s Gym&#8230;and Jay (the owner) sells the business to Jacob, it doesn&#8217;t matter as far as my authorization is concerned.  My authorization is with Jay&#8217;s Gym (which still exists), not with Jay.  That being said, this is assuming the authorization shows the Originator as Jay&#8217;s Gym and not Jay (the individual).</p>
<p>Now, if the sale is to a business that is planning to absorb the 1st business and Jay&#8217;s Gym would no longer exist, that would be a different issue.  There are 2 different schools of thought here:  1)  As long as the members are notified of the name change in writing, the existing authorization should be able to continue without issue &#8211; at least temporarily.  It would be in the best interest of the busiess to get new authorizations as the existing ones expire or come up for renewal.  2)  The other school of thought is that all new authorizations should be captured before any transactions are processed.  I disagree with this argument.  I think it places an uneccessary hardship on the business.</p>
<p>While I am not an attorney, and I&#8217;m sure you could find one to disagree with me, my position is based on experience in the industry.  I have seen this exact same thing happen a number of times and in nearly every case, new authorizations were acquired as existing ones expired or came up for renewal.  Those that went the &#8216;all new authorizations now&#8217; route were small in number.</p>
<p>I&#8217;m sure this is not exactly the answer you wanted, but ultimately, the decision is yours.  If you are still unsure what to do, then I would recommend seeking the assistance of your legal counsel.</p>
<p>I hope that helps,<br />
ACHGuy</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Jake</title>
		<link>http://ach-consulting.com/about/#comment-2172</link>
		<dc:creator><![CDATA[Jake]]></dc:creator>
		<pubDate>Tue, 23 Aug 2011 20:48:13 +0000</pubDate>
		<guid isPermaLink="false">#comment-2172</guid>
		<description><![CDATA[Hi ACH Guy,
What happens to an authorization for recurring entries when a merchant sells the business?  I see that Regulation E has a provision for a “successor institution” which includes a “successor payee” but I don’t see anything similar in the NACHA rules.  Can a successor merchant continue auto-debits based on authorization to the prior merchant?  Any help would be much appreciated!
Thank you,
Jake]]></description>
		<content:encoded><![CDATA[<p>Hi ACH Guy,<br />
What happens to an authorization for recurring entries when a merchant sells the business?  I see that Regulation E has a provision for a “successor institution” which includes a “successor payee” but I don’t see anything similar in the NACHA rules.  Can a successor merchant continue auto-debits based on authorization to the prior merchant?  Any help would be much appreciated!<br />
Thank you,<br />
Jake</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: achguy</title>
		<link>http://ach-consulting.com/about/#comment-2140</link>
		<dc:creator><![CDATA[achguy]]></dc:creator>
		<pubDate>Wed, 17 Aug 2011 17:56:02 +0000</pubDate>
		<guid isPermaLink="false">#comment-2140</guid>
		<description><![CDATA[Hello Christina,

I&#039;m sorry to hear that this Originator is causing you problems or at the very least being annoying.  A reminder to Originators everywhere...you warrant that all the information contained in every ACH transaction you process is accurate.  

With that being said, I have a couple of suggestions, assuming that you&#039;ve been returning the transactions as R03 - No Account or Unable to Locate.

1)  I&#039;m a huge proponent of communication, so my first suggestion is to reach out to the ODFI.  Explain what&#039;s happening and ask them to intervene.  Without having to remind them that they also warrant the accuracy of every ACH transaction their Originators process, they should step up, apologize (hopefully) and offer to reach out to the Originator directly.  At the very least consider what you would do if you were the ODFI being contacted and assume they would act in a similar manner.  Be nice and treat this as an opportunity to begin what could someday be a beneficial relationship...personal contacts at other FIs are always good.

2)  If you&#039;ve already tried option #1without success, file a Report of Possible Rules Violation against the Originator and/or the ODFI and submit to your local Regional Payments Association.  If the ODFI is also part of your RPA, then the RPA can reach out to them and it becomes the difference between the 400 lb. and the 600 lb. gorilla asking them to act.  Or, if the ODFI is not part of your RPA, the RPA can reach out to the ODFI&#039;s local RPA and you have the same affect, it will just take an extra day or 2.

Not sure who the ODFI is?  Check out:  http://www.fededirectory.frb.org//search_ACH.cfm 
Not a member of a RPA?  Doesn&#039;t matter, but you can find them here:  http://www.nacha.org/c/RegPayAssoc.cfm
Need a blank copy of the Rules Violation Report? Go to www.nacha.org and do a search for Rules Violation Report or Violation Form  both return a link to their Violation Form

I always like to assume that the Originator isn&#039;t misbehaving intentionally, only out of ignorance.  They may not have received proper instruction/education on how to respond to returns and a good ODFI will see this as an educational opportunity and act accordingly.

I hope this helps and I wish you luck,
ACHGuy]]></description>
		<content:encoded><![CDATA[<p>Hello Christina,</p>
<p>I&#8217;m sorry to hear that this Originator is causing you problems or at the very least being annoying.  A reminder to Originators everywhere&#8230;you warrant that all the information contained in every ACH transaction you process is accurate.  </p>
<p>With that being said, I have a couple of suggestions, assuming that you&#8217;ve been returning the transactions as R03 &#8211; No Account or Unable to Locate.</p>
<p>1)  I&#8217;m a huge proponent of communication, so my first suggestion is to reach out to the ODFI.  Explain what&#8217;s happening and ask them to intervene.  Without having to remind them that they also warrant the accuracy of every ACH transaction their Originators process, they should step up, apologize (hopefully) and offer to reach out to the Originator directly.  At the very least consider what you would do if you were the ODFI being contacted and assume they would act in a similar manner.  Be nice and treat this as an opportunity to begin what could someday be a beneficial relationship&#8230;personal contacts at other FIs are always good.</p>
<p>2)  If you&#8217;ve already tried option #1without success, file a Report of Possible Rules Violation against the Originator and/or the ODFI and submit to your local Regional Payments Association.  If the ODFI is also part of your RPA, then the RPA can reach out to them and it becomes the difference between the 400 lb. and the 600 lb. gorilla asking them to act.  Or, if the ODFI is not part of your RPA, the RPA can reach out to the ODFI&#8217;s local RPA and you have the same affect, it will just take an extra day or 2.</p>
<p>Not sure who the ODFI is?  Check out:  <a href="http://www.fededirectory.frb.org//search_ACH.cfm" rel="nofollow">http://www.fededirectory.frb.org//search_ACH.cfm</a><br />
Not a member of a RPA?  Doesn&#8217;t matter, but you can find them here:  <a href="http://www.nacha.org/c/RegPayAssoc.cfm" rel="nofollow">http://www.nacha.org/c/RegPayAssoc.cfm</a><br />
Need a blank copy of the Rules Violation Report? Go to <a href="http://www.nacha.org" rel="nofollow">http://www.nacha.org</a> and do a search for Rules Violation Report or Violation Form  both return a link to their Violation Form</p>
<p>I always like to assume that the Originator isn&#8217;t misbehaving intentionally, only out of ignorance.  They may not have received proper instruction/education on how to respond to returns and a good ODFI will see this as an educational opportunity and act accordingly.</p>
<p>I hope this helps and I wish you luck,<br />
ACHGuy</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: cbarbaro@1stconstitution.com</title>
		<link>http://ach-consulting.com/about/#comment-2138</link>
		<dc:creator><![CDATA[cbarbaro@1stconstitution.com]]></dc:creator>
		<pubDate>Wed, 17 Aug 2011 13:07:33 +0000</pubDate>
		<guid isPermaLink="false">#comment-2138</guid>
		<description><![CDATA[Hi ACHGuy, 

We keep receiving ACH payments from a company for non-existent customers and account numbers. Is there a way to stop these once and for all? It is time consuming to have to return these. 

Thanks, 
Christina]]></description>
		<content:encoded><![CDATA[<p>Hi ACHGuy, </p>
<p>We keep receiving ACH payments from a company for non-existent customers and account numbers. Is there a way to stop these once and for all? It is time consuming to have to return these. </p>
<p>Thanks,<br />
Christina</p>
]]></content:encoded>
	</item>
</channel>
</rss>
