My Bank is e-sign compliant for its bank statements only. Consumer lending would like to become e-sign compliant. Is it possible to pick and choose what departments become e-sign complaint and at what time, instead of doing a complete conversion at once?
Thank you!

Let's look at this from the direction of the law. It says you include a list of the types of documents that you propose to deliver electronically, describe the equipment, etc., needed, and obtain demonstrable consent. So from that end, you control the e-documents you are getting the authorization for. If they are all deposit-related, the loan department isn't involved. Or if they deliver their documents in a different way, they aren't included.

On the other hand, looking at the question from a broader perspective -- you can theoretically make the disclosures, etc., and obtain demonstrable consent for a full laundry list of electronic records that covers everything from soup to nuts, and you don't need to send them electronically. Even after you have demonstrable consent so that you CAN send them electronically, there is nothing requiring you (or a department) to so so in every case. E-SIGN enables e-deliver. It doesn't cripple paper delivery.

"ESIGN compliant" is not a clear statement of your goal. Instead, think in terms of "consent."

I'm puzzled by your mention of a conversion and department level compliance. "Consent" is obtained one customer at a time and it's illegal to force customers to accept e-delivery of federal disclosure documents that must be delivered "in writing."

In the past, you engaged in successful ESIGN "handshakes" with some percentage of the consumers who hold deposit (and possibly revolving credit) accounts for which periodic statements are required by federal regulations. These customers have declared their preference for and demonstrated their capability to use a particular type of electronic delivery. As John says, that consent is only valid for the types of e-documents you enumerated in the pre-consent disclosures you gave these customers. If that wording was broad, then it may already cover the consumer credit documents you now want to e-deliver. Review the terms of your existing consent agreements to see what additional types of documents might be covered in addition to the statements.

Regardless of the scope of the existing consent agreements, they are only valid for the type of e-delivery you and the customers have agreed and tested. To illustrate, let's say your statements are text documents that are parked on a secure server for the account holders to "pull" each cycle. If the consumer loan documents are also plain text and the consumer credit applicants "pull" them, then you have already done the demonstration and will simply need to expand the consent agreements with those customers who choose e-delivery of both types of documents. On the other hand, if the consumer credit documents are in a different format (let's say .pdf), are "pushed" to the applicants, are housed on a different server, or e-delivery differs in any other material way, then you will need to put the applicant through a full-blown demonstrable consent exercise that tests the different e-delivery method.

I think I understand the requirements but I need reassurance. We already have E-Sign consent for E-Statements. Our Lenders want to send the customers loan documents, (LE's, CD's and possibly other consumer loan docs). I need an E-Sign Consent form for the loan documents, being sent securely, right?

1. Do you offer E-Statements for HELOCs, credit cards, or any product other than deposits?

2. Are your E-Statements pushed to the customers, or do they pull them off your server?

3. Will you be able to use exactly the same method to put the LEs, CDs, and other consumer loan disclosures in the hands of these additional customers?

Jumping in here, hope nobody minds... but since there are several experts already involved I'm intrigued by the push/pull concept. We have a full blown ESIGN compliant setup for our e-statements and mortgage department, but our retail side is trying to use an Adobe version that doesn't feel like it provides an actual demonstrable consent, but I might be being too conservative. If the documents are delivered via web (kind of like Docusign) and the consumer "consents" by checking a box below the hyperlink of the ESIGN consent disclosure - do you feel this is compliant? I'm getting mixed answers and having a hard time working through everything. Curious if this is the same thing the OP is working with.

GM - The OP never followed up and explained in detail what his/her bank is actually doing. Likewise, we're still trying to understand the details of TB's situation. Very likely, yours is a 3rd variation. We can take your question to a new thread and link back to this one if you want.

You haven't given us enough detail about your retail e-delivery system to allow an evaluation. What are you delivering, how does it reach the consumer, and what steps does the customer take to test drive the system in advance?

Basically we're looking at a system that sends a link (via email) to someone, the hyperlink can be opened on any device and before the document loads the user must click a box that says they have read and understand the electronic delivery consent agreement, but that agreement isn't fully shown, instead it is a hyperlink on the page. Once they click the consent box and agree, the document shows. This document would show on any device since it is displayed on the webpage, and not in a format like PDF or word.

I've spoken with other banks that use this, and they feel it meets the demonstrable consent of ESIGN, but I can't wrap my head around how. They even told me that it was widely accepted for the banking community... but apparently not in the circles I run.

I don't know what we'd be delivering yet, but I'm worried rogue lenders will begin delivering timing specific disclosures (TRID, appraisals) and consider it okay without monitoring receipt.

Are you saying that each payload document is sent with its own consent agreement (like registered mail) and that there is no attempt to rely on one consent agreement for subsequent e-deliveries?

Yes, the consent agreement isn't visible unless clicked though (a hyperlink above proceeding) - and they have to choose "I agree" before viewing the document we are intending to be disclosed.

I'm having a hard time understanding the flow of events--probably because we are talking in general terms and not focusing on e-delivery of a particular document. You said earlier that your mortgage dept. has "a full blown ESIGN compliant setup", but then use one-off mortgage disclosures as examples of the possible use of this new system. (For your mortgage dept, does "full blown" really mean "statements only"?) It's impossible to determine the adequacy of any set of ESIGN pre-consent disclosures and test drive until you know what you want to e-deliver.

The timing and content of ESIGN's pre-consent disclosures and the method of "demonstration" depend on the payload. In turn, the payload documents are defined by an assortment of federal consumer protection laws and regs (TIL, TIS, RESPA, EFTA, etc.) Each of these laws has its own style and within each law/reg there can be different rules for delivering documents containing the various disclosures. Only when you have nailed down how and when the payload must be delivered can you "apply for the ESIGN license" to substitute electrons for paper.

I don't even know enough about TRID to get into trouble, but it's one of very few federal disclosure rules that include a requirement for consumer receipt. In the vast majority of cases, acknowledgement and receipt requirements come from CYA internal policies. ESIGN and "reciept" are mutually exclusive. The whole point to ESIGN's unusual design is to obviate the need for confirmations of receipt at the time of each e-delivery. Congress determined that one test drive will prove that the consumer has the equipment and savvy to use your e-delivery system and then there's a legal asumption (like the "mailbox rule") that the system works from that point on. When you attach a new consent requirement to each document you e-deliver, it's like towing a muscle car with a horse.

It seems the next step must be to forget the technology for now and focus your review on the specific payload documents highest on your lenders' wish list. After you identify the documents, examine their content, and then catalog (by CFR cite) which federal disclosures they contain. Then, review the laws/regs that require each disclosure and determine if each one must be delivered "in writing" (if the docs don't have to be delivered "in writing", ESIGN becomes unnecessary), the timing for each payload disclosure, and the need (if any) for acknowledgement of receipt. Then, determine what file format and e-delivery method (push/pull) will be used to put the e-document in your customers' hands. Using what you've learned, determine whether the proposed e-delivery system can meet the necessary timing requirements for the payload documents. If everything still looks good, determine what must be included in the ESIGN pre-consent disclosures and how the "test drive" must work in order to prove beyond any doubt that each customer willing to consent possesses and knows how to use the necessary hardware and software. Finally, tell your lenders (in writing, preferably with a formal procedure that can be audited) which documents they can push through the new tree-free system and what you will do to them if they exceed that authority! (Remember: if you can't make your ESIGN consent hold up in court, violations are systemic and the penalties could be the same as if you didn't deliver the payload disclosures at all.)

As a reminder, ESIGN's pre-consent disclosures must contain the following, as applicable:
1. a statement of the hardware and software requirements for access to and retention of the electronic records
2. "clear and conspicuous statements" including:
a. any right or option to have the payload document provided or made available on paper
b. the right (not option) to withdraw consent and the cost and consequences of so doing
c. the scope of consent (can be a single document, every document you will ever send, or anything in-between)
d. what procedures the customer must follow to withdraw consent at a later date
e. how the customer must notify you if his/her electronic contact information (email address, etc.) changes in the future
f. how the customer can request paper copies of any or all e-delivered documents and the cost

Be careful not to get carried away with 2.c. Only include those documents you realistically expect to e-deliver. You don't want to confuse customers by switching back & forth between paper and electrons without advance notice.

I have a quick e-Sign related question and would like your input. Our core processor, deposit platform vendor and on-line banking provider are one in the same. (We recently added the on-line banking piece w/ this provider.) Our deposit disclosures do not include any type of e-Sign disclosure, nor does OLB include one. Currently the only documents we provide electronically are e-statements and our OLB terms and agreements. We questioned the vendor regarding the e-Sign prior consent requirements and was told that it was our responsibility to ensure compliance w/ e-Sign. Just wondering if this is the norm and it does fall on us or if other banks' vendors ensure e-Sign compliance? How & at what point do you provide an e-Sign disclosure at account opening, before opting in to e-statements, or before enrolling in OLB?

If the accounts are subject to Regulation E (all consumer transaction accounts are), there is a periodic written statement requirement in the regulation. So, you will have to obtain e-SIGN demonstrable consent before issuing the first electronic-only periodic statement on the account. I can't tell you whether it's the norm for service providers to offer e-SIGN compliance steps as part of their on-boarding processes; I can tell you that it's the bank's responsibility to ensure than the e-SIGN process is completed, regardless of how it's done.

You have a wise vendor. Most will probably assure you that they're covering everything that needs to be done. Looking at the list of pre-consent disclosures above, you can see that several items are controlled strictly by bank policy--not the vendor's technology services.

Whenever I see questions relating to "ESIGN compliance", I worry that the inquirer is trying to manage ESIGN like a banking regulation. That approach leads to problems.

Yes, ESIGN requires disclosures--but only in cases where the bank and a customer both agree to set up e-delivery of one or more kind of documents. You can't require groups of customers to accept e-delivery of documents, so it's probably a bad idea to make general portfolio-wide distributions of ESIGN pre-consent disclosures.

The short answer to your question is that you must provide (once) ESIGN's pre-consent disclosures:
1. as the first step in the e-delivery opt-in process, and
2. prior to obtaining the customer's consent, and
3. prior to e-delivering a payload document.