Transcript pdlba.com

Disclaimer
This presentation is provided with the understanding that the
presenter is not rendering legal advice or services. Laws are
constantly changing, and each federal law, state law, and regulation
should be checked by legal counsel for the most current version.
We make no claims, promises, or guarantees about the accuracy,
completeness, or adequacy of the information contained in this
presentation. Do not act upon this information without seeking
the advice of an attorney.
This outline is intended to be informational. It does not provide
legal advice. Neither your attendance nor the presenters answering
a specific audience member question creates an attorney-client
relationship.
Internet-Initiated Entries
• General Overview of the WEB Entry
• Single and Recurring Entries
• Authorization Requirements
• Signed and Similarly Authenticated
• Risk Management
• ODFI Warranties
• Originator Obligations
• Data Security
• Revocation and Stop Payments
Internet-Initiated Entries
Brief History: NACHA added in 2001, along with Telephone-Initiated Entries. NACHA added heightened
security requirements due to the “potentially greater risk profile.”
Definition: "WEB entry" or "WEB“ means a debit entry initiated by an Originator pursuant to an authorization
that is obtained from the Receiver via the Internet to effect a transfer of funds from a Consumer Account of
the Receiver.
General Rule: A WEB entry may be transmitted by an Originator pursuant to an authorization that is obtained
from the Receiver via the Internet to effect a transfer of funds from a Consumer Account of the Receiver.
2 Types Single and Recurring: For a recurring WEB entry, field entry must contain the value "R". For a SingleEntry WEB entry, field must contain the value "S".
Guidelines: Originators initiating debit entries (both recurring and Single-Entry) to a consumer account pursuant
to an authorization that is obtained from the Receiver via the Internet are required to utilize the WEB
(Internet-Initiated Entry) Standard Entry Class Code. This SEC Code is intended to address unique risk
issues that are inherent to the Internet payment environment through requirements for added security
procedures and obligations.
Rules of Construction. Where these rules specify requirements for transactions initiated in a particular
way, including, but not limited to rules for ARC, BOC, POP, TEL and WEB entries, these rules specify the
minimum requirements for entries initiated by the means described for each type of entry, and the proper
Standard Entry Class (SEC) Codes for these entries must be used. Where these rules provide that
authorization for an entry may be obtained by notice to the Receiver, authorization may also be obtained by
means of a signed written authorization that meets the requirements of subsection 2.1.2 (Receiver
Authorization and Agreement) if all of the other requirements for the type of entry are met.
SINGLE-ENTRY v. RECURRING
• Single: A Single-Entry payment means a one-time transfer of funds initiated
by an Originator in accordance with the Receiver's authorization for a single
ACH debit to the Receiver's account. One example of a Single-Entry WEB
transaction would be a consumer purchase of a book online.
• Recurring: For purposes of WEB entries, a recurring payment is: 1) an entry
that has been set up to occur, based on the Receiver's authorization obtained
via the Internet, at regular intervals without any additional intervention of the
consumer (i.e., a monthly debit to the consumer's account for a mortgage
payment); or 2) multiple entries, based on an authorization provided by the
consumer establishing a relationship with the Originator for a specific type of
activity, that are originated each time upon the specific instructions of the
consumer (i.e., an instruction to a broker to purchase or sell securities).
AUTHORIZATION REQUIREMENTS
•
Originators of WEB entries must obtain the consumer's authorization prior to
initiating a debit entry under this application.
•
The NACHA Operating Rules do not prescribe specific authorization language for the
WEB application. However, the authorization must conform to the requirements of the
NACHA Operating Rules, which require that the authorization (1) be in a writing that is
signed or similarly authenticated by the Receiver, (2) be readily identifiable as an ACH
debit authorization, (3) clearly and conspicuously state its terms, and (4) for recurring
payments only, must provide the Receiver with a method to revoke their authorization by
notifying the Originator in the manner prescribed.
•
Writing. The consumer must “be able to read” the authorization language displayed on a
computer screen or other visual display. The Originator should prompt the consumer to
print the authorization and retain a copy. The Originator must be able to provide the
consumer with a hard copy of the authorization if requested to do so. Only the
consumer may authorize the WEB transaction, and not a Third-Party Service Provider on
behalf of the consumer.
Signed or Similarly Authenticated
•
Similarly Authenticated . The similarly authenticated standard permits signed, written
authorizations to be provided electronically.
•
These writing and signature requirements are satisfied by compliance with the Electronic
Signatures in Global and National Commerce Act (15 U.S.C. 7001 et seq.), which defines
electronic records and electronic signatures.
•
To satisfy the requirements of Regulation E and the NACHA Operating Rules, the
authentication method chosen must evidence both the consumer's identity and his
assent to the authorization. Examples of methods used to similarly authenticate an
authorization include, but are not limited to, the use of digital signatures, codes, shared
secrets, PINs, etc.
•
Authorization and the authentication of that authorization must occur
simultaneously. It is not considered acceptable authentication to have identified a
consumer at the time of logging on to a website and then later consider that log-in
as an authentication for purposes of authorizing an ACH debit. Nor is it considered
acceptable to authenticate an authorization on a website simply by a click-through process.
RISK MANAGEMENT
• To help mitigate the added risk associated with Internet-based payments,
Originators are obligated to comply with stringent risk management
requirements when originating WEB entries.
• At a minimum, Originators of such entries must implement the
following risk management techniques:
– Authentication,
– Fraudulent Transaction Detection Systems,
– Verification of Routing Numbers,
– Security of Internet Session, and
– Annual Security Audits.
Risk Management – Authentication
•
The more robust the authentication, the less likely the transaction will be fraudulent and the less likely
the payment will be returned to the Originator as unauthorized.
•
Originators with an established business relationship with the consumer – whether established online, in
person, over the telephone, or some other method – can usually authenticate those customers using
shared secrets such as a PIN, password or previous transaction history.
•
There is no standard authentication process being used online to identify and authenticate unknown
individuals on the Internet. Common examples in use today include asking for several forms of
identifying information and checking that information against databases, asking challenge questions
based upon credit bureau or other information, or sending the consumer a specific piece of information,
either online or offline, and then asking the consumer to verify that information as a second step in the
authentication process.
•
Some other factors to consider in selecting an authentication method that is commercially reasonable
include typical transaction amount, type of goods offered, method of delivery, and control of goods or
funds. It is important to note that it will never be considered commercially reasonable to have done
nothing. Similarly, assigning a password and allowing the Receiver to use that password in the same
Internet session as the sole method of authenticating the Receiver is also not commercially reasonable.
Risk Management - Fraudulent
Transaction Detection Systems
•
Examples of fraudulent transaction detection systems are systems that track payment
history, behavior, purchase type, delivery information, etc.
•
Factors to consider when choosing a fraudulent transaction detection system include the
number of transactions processed by the Originator, the average dollar size of each
transaction, the typical relationship with the consumer (previously existing or new), and the
type of goods or services being sold.
•
A fraudulent transaction detection system must be deployed no matter how small the
transaction amount or type.
Risk Management - Verification of
Routing Numbers
•
To minimize exception processing related to WEB entries, each Originator is required to
employ commercially reasonable procedures to verify that routing numbers are valid.
•
Originators should try to ensure that the consumer enters the routing number correctly and
that it is a valid RDFI routing number for ACH transactions.
•
Although the NACHA Operating Rules do not require Originators to verify the validity of
Receiver account number structures, it is strongly recommended that they employ
procedures to do so.
•
Verifying the validity of routing numbers can be accomplished as either a component of a
fraudulent transaction detection system, through a separate database or directory (either
commercial or proprietary), or through other methods devised by the Originator, for
example manual intervention such as calling the Receiver's financial institution.
Risk Management - Security of
Internet Session
•
Originators of WEB entries are required to either (1) encrypt the Receiver's banking
information using a commercially reasonable security technology that, at a minimum, is
equivalent to 128-bit RC4 encryption technology, or (2) transmit the Receiver's banking
information via a secure session utilizing a commercially reasonable security technology that
provides a level of security that, at a minimum, is equivalent to 128-bit RC4 encryption
technology.
•
The use of such encryption technology must, at a minimum, be employed prior to the keyentry of the Receiver's banking information and through the transmission of the data to the
Originator.
•
Currently, 128-bit RC4 encryption technology is the standard for financial transactions and
is considered commercially reasonable. If technological advancements drive the
commercially reasonable standard to change, Originators should comply with the new
standard.
•
Risk Management - Annual Security
Audits
The NACHA Operating Rules for WEB transactions require Originators to conduct an audit at least
once a year to ensure that Receivers' financial information is protected by security practices and
procedures that ensure that the financial information that the Originator obtains from consumers is
protected by security practices that include adequate levels of:
–
1) physical security to protect against theft, tampering, or damage,
–
2) personnel and access controls to protect against unauthorized access and use, and
–
3) network security to ensure secure capture, storage and distribution of financial information. Such an audit must
be completed annually.
•
This audit requirement can be met in several ways. It can be a component of a comprehensive internal
or external audit, or it can be an independent audit or security seal program that covers these security
issues.
•
An Originator that is already conducting an audit of these practices and procedures for another area of
its business is not required to have two separate audits. As long as the audit covers these components, it
will meet the requirement.
•
While the NACHA Operating Rules only require Originators to conduct an audit of their security
practices and procedures once a year, many companies are now opting to audit these practices biannually or even quarterly due to the rapid change of technology and security risks. It is therefore highly
recommended that Originators of WEB entries also conduct more frequent audits.
•
•
•
•
Risk Management - Annual Security
Audits
The minimum components that need to be audited in order to be in compliance with the audit requirement are:
(1) Physical security to protect against theft, tampering or damage
–
Critical network, server, and telecommunications equipment should be placed in physically secure locations that permit access only to
authorized personnel.
–
Firewalls must be fully deployed with secured processes for administering those firewalls.
–
Firewalls must protect websites from inappropriate and unauthorized access.
–
Disaster recovery plans must be developed and reviewed periodically.
(2) Personnel and access controls to protect against unauthorized access and use
–
A formal set of security policies and procedures must be developed that clearly outline the corporate rules governing access to sensitive
financial data.
–
Hiring procedures should be developed that will, at a minimum, verify application information and check references on new employees
that will have access to Receiver financial information.
–
Relevant employees must be educated on information security and company practices and their individual responsibilities.
–
Access controls should be in place to:
–
Limit employee access to secure areas and to documents/files that contain Receiver financial information.
–
Ensure that terminated employees have no access to secure information and areas.
–
Permit visitors to these areas and information only when absolutely necessary and ensure they are accompanied by an employee at all times.
–
Restrict access from external networks to authenticated users (i.e. by passwords or login codes).
–
Ensure that one person acting alone cannot circumvent safeguards, i.e. dual control procedures are in place.
–
– Procedures and audit trails need to be established to scrutinize activities of users with access to Receiver information in order to detect
anomalies.
(3) Network security to ensure secure capture, storage and distribution
–
All Receiver financial information should be kept behind firewalls and in an area inaccessible from the Internet.
–
A data retention schedule should be developed that covers the policies on how to handle the data from the time of capture to destruction.
ODFI Warranties
In addition to the other warranties contained within the NACHA rules, each ODFI initiating a WEB entry makes
various warrants to each RDFI, ACH Operator, and Association including the following:
1 Fraud Detection Systems. Each Originator employs a commercially reasonable fraudulent transaction detection system to screen each entry.
2 Verification of Receiver's Identity. The Originator employs commercially reasonable methods of authentication to verify the Receiver's identity.
3 ODFI Exposure Limits. In the case of a WEB entry sent or transmitted to an ODFI directly by an Originator that is not a natural person or by a Third-Party
Sender, the ODFI has (1) established procedures to monitor, on an on-going basis, the credit- worthiness of the Originator or Third-Party Sender, (2)
established an exposure limit for the Originator or Third- Party Sender, (3) implemented procedures to review that exposure limit periodically, and (4)
implemented procedures to monitor entries sent or transmitted by the Originator or Third-Party Sender relative to its exposure limit across multiple
settlement dates.
4 Verification of Routing Numbers. Each Originator that originates WEB entries has used commercially reasonable procedures to verify that routing numbers
are valid.
5 WEB Annual Audit. Each Originator that originates WEB entries shall conduct or have conducted annual audits to ensure that the financial information it
obtains from Receivers is protected by security practices and procedures that include, at a minimum, adequate levels of (1) physical security to protect
against theft, tampering, or damage, (2) personnel and access controls to protect against unauthorized access and use, and (3) network security to ensure
secure capture, storage, and distribution.
6 Liability for Breach of Warranty. Each ODFI breaching any of the warranties contained within subsection 2.11.2 (ODFI Warranties) shall indemnify every
RDFI, ACH Operator, Association, and any other party covered by the warranty from and against any and all resulting claim, demand, loss, liability, or
expense, including attorneys' fees and costs, resulting directly or indirectly from the breach of these warranties. In addition, in the case of a Consumer
Account, the ODFI shall indemnify every RDFI, ACH Operator, Association, and any other party covered by the warranty from and against any and all
resulting claim, demand, loss, liability, or expense based on the ground that the failure of the ODFI to comply with any provision of these rules resulted,
either directly or indirectly, in the violation by an RDFI of the Federal Electronic Fund Transfer Act or Federal Reserve Board Regulation E.
Obligations of Originators
1
Fraud Detection Systems. Each Originator originating WEB entries must employ a
commercially reasonable fraudulent transaction detection system to screen each entry.
2
Verification of Routing Numbers. Each Originator that originates WEB entries must use
commercially reasonable procedures to verify that routing numbers are valid.
3
Verification of Receiver's Identity. Each Originator that originates WEB entries must employ
commercially reasonable methods of authentication to verify the identity of the Receiver.
4
WEB Annual Audit. Each Originator that originates WEB entries shall conduct or have
conducted annual audits to ensure that the financial information it obtains from Receivers is
protected by security practices and procedures that include, at a minimum, adequate levels of (1)
physical security to protect against theft, tampering, or damage, (2) personnel and access controls
to protect against unauthorized access and use, and (3) network security to ensure secure capture,
storage, and distribution.
ACH DATA SECURITY
REQUIREMENTS
•
For all ACH transactions that involve the exchange or transmission of banking information
(which includes, but is not limited to, an entry, entry data, a routing number, an account number, and a
PIN or other identification symbol) via an Unsecured Electronic Network, the NACHA Operating Rules
require that such banking information be either (1) encrypted using a commercially reasonable security
technology that, at a minimum, is equivalent to 128-bit RC4 encryption technology, or (2) transmitted
via a secure session that utilizes a commercially reasonable security technology that provides a level of
security that, at a minimum, is equivalent to 128-bit RC4 encryption technology.
•
These encryption requirements must be employed prior to the key-entry and through the
transmission of any banking information exchanged over such an Unsecured Electronic Network
between (1) an Originator and a Receiver; (2) an Originator and an ODFI; (3) an ODFI and an ACH
Operator; (4) an ACH Operator and an RDFI; and (5) an Originator, ODFI, RDFI, or ACH Operator
and a Third-Party Service Provider.
•
Transmissions or exchanges of banking information using voice or keypad inputs from a wireline or
wireless telephone are not subject to this data security requirement unless the telephone is used
to access the Internet. An application in which the Originator obtains information from the Receiver
by another means (such as the telephone) and then key enters the information via the Internet is, for
example, subject to these data security requirements. However, information delivered via telephone line,
such as a leased line, or dialed into a financial institution's modem pool is not subject to this
requirement.
Authorization Revoked vs. Stop
Payment
Authorization Revoked
•
The Return Reason Code (R07) used to identify this type of return tells the Originator that there was once an
authorization in place, but that authorization, in its entirety, has since been rescinded.
•
As a result, all future entries related to this authorization must be stopped. In order to initiate
subsequent entries, the Originator would need to obtain a new authorization from the Receiver.
•
When using this code, the RDFI is warranting that it has obtained a written statement under penalty of
perjury from the Receiver stating that the Receiver has revoked the authorization with the Originator. The
RDFI should develop procedures to accept and retain copies of written statements under penalty of perjury.
RDFIs should ensure that all customer service personnel understand the difference between stop payment
orders and revocation of authorization.
Stop Payment
•
Just as a stop payment on a check is for one check only, a stop payment in the ACH Network is for one
ACH payment only. A return is initiated with a Return Reason Code of R08.
•
Because the R08 Code is not a request to stop all future payments, the RDFI and the Receiver can expect
subsequent payments to be initiated. Return entries initiated due to a stop payment order having been
placed on the ACH entry must be transmitted to the RDFI's ACH Operator by its deposit deadline for the
return entry to be made available to the ODFI no later than the opening of business on the second banking
day following the settlement date of the original entry.
Stop Payment
General Rule for all entries except ARC, BOC, RCK, POP, Single-Entry WEB, and TEL entries, a
Receiver may stop the payment of a debit entry initiated or to be initiated to a Consumer Account
of the Receiver by providing either verbal or written notification to the RDFI at least three
banking days before the scheduled date of the transfer. An RDFI may honor a stop payment
order received within the three-banking-day limit prescribed above, and, if it honors such a
request, the RDFI has no resultant liability or responsibility to any Originator, ODFI, or other
person having any interest in the entry.
For ARC, BOC, RCK, POP, Single- Entry WEB, and TEL entries, the stop payment order must be
provided to the RDFI at such time and in such manner as to allow the RDFI a reasonable
opportunity to act upon the stop payment order prior to acting on the debit entry. The RDFI
may require that written confirmation of a verbal stop payment order be made within 14 days of
a verbal stop payment order, provided that the RDFI notifies the Receiver of this requirement
and provides an address to which the written confirmation should be sent at the time the verbal
order is provided. If the RDFI requires written confirmation, the verbal stop payment order will
cease to be binding after 14 days. A Receiver may withdraw a stop payment order by providing
written notice to the RDFI. A stop payment order will remain in effect (1) for six months from
the date of the stop payment order, (2) until payment of the debit entry has been stopped, or (3)
until the Receiver withdraws the stop payment order, whichever occurs earliest.
Right to Revoke Not Required
on Single Entry Web Entries
NACHA OPERATING RULES 2.1.3: Require ACH authorizations “must be readily
identifiable as an authorization, must clearly and conspicuously state its terms, and, for
all entries except POP entries and Single- Entry WEB entries, the authorization
must provide that the Receiver may revoke the authorization only by notifying
the Originator in the manner specified in the authorization.
Revocation of Authorization. POP entries, TEL entries, and Single-Entry WEB Entries
may not be returned by an RDFI as "Authorization Revoked." Because these
transactions are one-time payments where the Originator will generally process
the transaction immediately after the purchase is complete, the Receiver is
precluded from revoking authorization for the transaction. The Receiver does,
however, retain his right to place a stop payment order on such transactions
and to request the return of any unauthorized entry.)
ACH TEL Entry
•Definition
•General Rule
•ODFI Warranty
•Obligation of Origination
•Record of Authorization
•Stop Payment
•Operating Guidelines
TEL – Definition
• Means a Single-Entry debit initiated by an Originator pursuant
to an oral authorization obtained over the telephone to effect a
transfer of funds from a Consumer Account.
• This type of entry may be used for a Single-Entry for which
there is no standing authorization.
• A TEL entry may only be used when there is an Existing
Relationship between the Originator and the Receiver OR
• When there is not an Existing Relationship between the
Originator and the Receiver, when the Receiver initiates the
telephone call (14.1.63).
TEL – General Rule
• Receiver (Customer) has orally authorized the
Originator (Company) to initiate a debit entry
(2.1.8)
• Authorization must be readily identifiable as
an authorization and must state its terms
(2.1.8)
TEL – General Rule
• At a Minimum Authorization must include (2.1.8):
– Date on or after which ACH debit to the Receiver’s account will
occur
– Amount of the transaction
– Receiver’s Name
– Telephone number for Receiver’s inquiries that is answered during
normal business hours
– Date of Receiver’s oral authorization
– A statement by the Originator that the authorization obtained
from the Receiver is for a a single entry ACH Debit
TEL – General Rule
• Originator must either
– (1) taper record the oral authorization, or
– (2) provide the Receiver with written notice
confirming the oral authorization prior to the
Settlement Date of the entry (2.1.8).
TEL – ODFI Warranty
• Verification of Receiver’s Identity (2.13.2.1)
– Commercially Reasonable Procedures
– Past buying history, mother’s maiden name, caller I.D.
information (OG Ch. 17 – D- 4).
• Verification of Routing Number (2.13.2.2)
– Commercially Reasonable Procedures
– Use of database or contacting consumer’s financial
institution (OG Ch. 17 – D – 4).
TEL – Operating Guidelines (OG)
• Because TEL entries are Single-Entry debits,
Originators must be aware that they must
obtain a separate oral authorization from the
consumer for each entry to the consumer’s
account (Ch. 17 – A).
TEL – Stop Payment
• For ARC, BOCK, RCK, POP, Single-Entry WEB, and TEL,
the stop payment order must be provided at such time and in
such manner as to allow a reasonable opportunity to act
upon the stop payment order prior to acting on the Debit
entry (8.4).
• Customer is precluded from revoking authorization because
it is a one time payment authorized at the time goods or
services are purchased (OG-Ch.17– E-2).
TEL – OG – Authorization
Requirements
• For an oral authorization obtained over the telephone to be
in accordance with the requirements of the NACHA
Operating Rules,
– (1) the Originator must state clearly during the telephone
conversation that the consumer is authorizing an ACH
debit entry,
– (2) the Originator must express the terms of the
authorization in a clear manner, and
– (3) the Receiver must unambiguously express
consent…Silence is not express consent (Ch. 17 – D).
Remotely Created Checks
• What is a remotely created check?
• Why use a remotely created check?
• Issues with remotely created checks
What is a remotely created check?
• Federal (Reg. CC and J) – “a check that is not created by the
paying bank and that does not bear a signature applied, or
purported to be applied, by the person on whose account the
check is drawn.”
• UCC defines “remotely-created consumer item” as “an item
drawn on a consumer account, which is not created by the
paying bank and does not bear a hand written signature
purporting to be the signature of the drawer.”
What is a remotely created check?
• An image of a “check” on your web page is
NOT a remotely created check.
What is a remotely created check?
• E-Sign – does not apply to Article 3 & 4 negotiable
instruments
• UETA – Section 16 provides for the electronic
signing of a promissory note but not a check.
What is a remotely created check?
• Must obtain an authorization.
• Must create a physical check to present on
behalf of customer.
• Typically has customer’s printed or typed
name or bears a statement that the customer
authorized the check.
Why use remotely created checks?
• Some states require the taking of a “check” –
(e.g. California, Tennessee, etc.)
• As an alternative payment method
Issues with remotely created checks
• Bank relationship – warranties (alters Price v.
Neal standard)
• Customer rights – same as with standard
checks
• NSF fees – can you get them? (compare to
ACH)
Issues continued . . .
• NACHA rules
– Back Office Conversion (BOC) and Accounts
Receivable Entries (ARC); the following may not
be used as source documents for BOC and ARC
entries:
• Demand drafts and third-party drafts that do
not contain the signature of the Receiver
Issues continued . . .
• NACHA rules
– Represented Check Entries (RCK); Items that are
ineligible for transmission as RCK entries
include, but are not limited to:
• Demand drafts and third-party drafts that do not
contain the signature of the Receiver (e.g., the drawer
does not sign a check but authorizes another party to
debit his account via a draft).
Issues continued . . .
• Can be processed via Check 21.
• Fraud – need to implement fraud prevention
policy (Barney Frank’s watch list; 35 AGs
recommended to Federal Reserve that RCCs
be prohibited)
Contact:
Ronald D. Gorsline * Justin B. Hosie
H. Blake Sims * G. Clinton Heyworth
Chambliss, Bahner & Stophel, P.C.
1000 Tallan Building
Two Union Square
Chattanooga, Tennessee 37402
(423) 756-3000
[email protected]
[email protected]
[email protected]
[email protected]
www.cbslawfirm.com