<?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 for Everything ACH</title>
	<atom:link href="http://ach-consulting.com/comments/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>Comment on About Everything ACH 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>Comment on About Everything ACH 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>Comment on About Everything ACH 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>Comment on About Everything ACH 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>Comment on Going It Alone&#8230; by achguy</title>
		<link>http://ach-consulting.com/2010/09/16/going-it-alone/#comment-2625</link>
		<dc:creator><![CDATA[achguy]]></dc:creator>
		<pubDate>Thu, 27 Oct 2011 19:22:18 +0000</pubDate>
		<guid isPermaLink="false">http://ach-consulting.com/?p=344#comment-2625</guid>
		<description><![CDATA[Hey Monica,

Unfortunately, I am not familiar with these guys.  It doesn&#039;t mean anything one way or the other, it just means that I haven&#039;t heard of them.  

If you are considering adding ACH to your arsenal of payment options, check out my post about ODFI vs. Third Party Processor.  While it was intended to help you decide between those two options, it will also give you some food-for-thought on your due diligence process.  If you are still in the early consideration stages, I encourage you to consider all your options.

Sorry I cannot be or more help, but please let me know how it works out?

Have a great day,
ACHGuy]]></description>
		<content:encoded><![CDATA[<p>Hey Monica,</p>
<p>Unfortunately, I am not familiar with these guys.  It doesn&#8217;t mean anything one way or the other, it just means that I haven&#8217;t heard of them.  </p>
<p>If you are considering adding ACH to your arsenal of payment options, check out my post about ODFI vs. Third Party Processor.  While it was intended to help you decide between those two options, it will also give you some food-for-thought on your due diligence process.  If you are still in the early consideration stages, I encourage you to consider all your options.</p>
<p>Sorry I cannot be or more help, but please let me know how it works out?</p>
<p>Have a great day,<br />
ACHGuy</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on About Everything ACH 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>Comment on Going It Alone&#8230; by Monica Schmidt</title>
		<link>http://ach-consulting.com/2010/09/16/going-it-alone/#comment-2623</link>
		<dc:creator><![CDATA[Monica Schmidt]]></dc:creator>
		<pubDate>Thu, 27 Oct 2011 18:43:14 +0000</pubDate>
		<guid isPermaLink="false">http://ach-consulting.com/?p=344#comment-2623</guid>
		<description><![CDATA[Hi there, ACH Guy! I have a question about ACH processing. Someone from www.m2wwsolutions.com called me a week ago and asked if I considered using ACH as a payment option for my website. Have you heard of the company? They have been around for 25 years, is what they told me, but it doesn’t sound familiar. Any feedback would be greatly appreciated!]]></description>
		<content:encoded><![CDATA[<p>Hi there, ACH Guy! I have a question about ACH processing. Someone from <a href="http://www.m2wwsolutions.com" rel="nofollow">http://www.m2wwsolutions.com</a> called me a week ago and asked if I considered using ACH as a payment option for my website. Have you heard of the company? They have been around for 25 years, is what they told me, but it doesn’t sound familiar. Any feedback would be greatly appreciated!</p>
]]></content:encoded>
	</item>
	<item>
		<title>Comment on About Everything ACH 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>Comment on About Everything ACH 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>Comment on About Everything ACH 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>
</channel>
</rss>

