So Good Morning America (ABC) had a segment this morning on P2P payments focusing on Apple Pay, Venmo and Zelle (I think it was). The conclusion was that if a payment is sent to the wrong person, sorry about that. Consumers feel like something has to be done but the police say it isn't a crime. (I see a civil case for undue enrichment, but would they generally bother?) In one example a Chicago man sent $1700 to the wrong person, who then wasn't answering his phone. Big surprise. Chase said they'd try to help recover funds on a case by case basis. In his case Chase gave him $800 back. I think Chase went above and beyond (and may have set a dangerous precedent.)

Consumers - when the bank follows your directions, why should the bank pay for your mistake? <----- My recommended addition to Reg E disclosures.

Do you see these as an "unauthorized EFT?"

I don't, but it seems like these could fall within the realm of a Reg. E error. Could it be claimed this meets the definition of "(ii) An incorrect electronic fund transfer to or from the consumer's account;" In this instance, instead of the normal situation where the incorrect eft is because the amount is wrong, could it be considered incorrect because the recipient is wrong?

The P2P service simply followed the customer's instructions and sent the correct dollar amount in accordance with those instructions There's nothing unauthorized here.

The only way Reg E will cover a P2P transfer is if:

1. The customer says send the money to Account 555-555-1234 and someone at the bank manually changes the destination to 555-555-2345. (That's an error because the customer's instructions weren't followed.)

2. My account number and routing number / debit card number are compromised and the bad guys originate payments without my knowledge or consent.

If I get tricked by the bad guys into sending a P2P payment and it turns out the beautiful woman I met online is not a woman at all, that's too bad for me. The P2P service followed my instructions and sent the correct amount to the destination I provided. Reg E doesn't cover that.

Unfortunately we recently had Brian's 2nd instance (bad guys got access to phone through fraud) and determined this was a Reg E claim. The dispute where the customer was purchasing a puppy, which didn't exist, was determined not to be a dispute because the transactions weren't unauthorized.

We do limit our P2P transfers to $300 per transfer; however in the second instance above the customer sent multiple transactions. Additionally we encourage our customers to only use Zelle to people they know and trust.

Reminds me - I need to thoroughly read our disclosure again.

Yes, I'm not arguing the unauthorized piece, but, arther the "incorrect eft" angle; however, I have concluded the same.

Follow on question regarding whether a Zelle transaction is covered under Reg E 1005.11 "(ii) An incorrect electronic fund transfer to or from the consumer's account" - Scenario: Customer initiates an authorized Zelle transaction and bank follows customer's instructions and correct dollar is debited and posted to customer's account; however, recipient never received the money. Two questions:
1. If the recipient is also our customer, and therefore we can confirm that the corresponding Zelle transfer was never credited/posted to the account, is this a Reg E covered error under section 1005.11 and would require all of the applicable error resolution steps?

2. If the recipient is NOT our customer, and therefore we can only "see" the transaction instruction leaving our bank/customer's account, is this same scenario a Reg E covered error under section 1005.11 and would require all of the applicable error resolution steps? Could we treat it like an ACH where our "investigation" would stop at our payment instruction that went out the door?

I have been told that because the correct dollar amount was posted to the customer's account and the Zelle instruction went correctly to the intended recipient, even though we have clear evidence that the recipient did not actually receive the money, that it is NOT a Reg E covered error and that the customer's "claim" was corrected treated as a "Non Reg E Proof of Payment" claim and did not need to follow the Error Resolution under 1105.11. Thoughts?

Do you know where the intended recipient or the account for the intended recipient is located?

John - In my scenario, the intended recipient is in the US and the sender is in the US.

Both are our customers. So the main question is whether the Zelle transaction that was correctly and timely debited from our customer's account but was not correctly and timely credited to our other customer's account is a covered Reg E "error" and subject to all of the error resolution steps as outlined in 1005.11.

The dollar amount was correctly debited and the Zelle transaction was processed to the correct recipient, i.e. the customer's payment instructions contained no error. However, for undetermined reasons, the Zelle transaction did not go through to the recipient's account. I am being told that this scenario is NOT Reg E covered because the correct dollar amount was debited and posted to the sender's account - so there was no "error".

But that does not make sense to me as clearly there was an "error" - say $200 dollars were requested to be sent but the recipient received $0 - That seems like a clear "error" under the 1005.11(a)(ii) an incorrect electronic fund transfer to or from the consumer's account".

The recipient has a Reg E claim in the incorrect EFT to their account.

Thank you, Andy and John. With my scenario, the sender and the receiver of the Zelle transfer just happened to be our customers, each with different deposit accounts. The sender called to notify us of the "error" in that the intended receiver did not receive the funds. If I am understanding you correctly, we did NOT need to treat the sender's alleged error as Reg E covered; however, if the intended receiver had called us instead to say that he had not received the funds from the sender, then we WOULD have to treat his alleged error as Reg E covered.

And we would have given the intended receiver the $200 that the sender had instructed through Zelle to be sent to him.

However, that's "easy" to see because both parties to the single Zelle transaction have their accounts with us. But had the intended receiver NOT been our customer, what then? We just deny the sender's claim that the Zelle transaction didn't go through and that it isn't Reg E covered error cause the instruction went out as intended and the correct amount of $200 was debited from his account?

And then the intended receiver would have to make a Reg E claim with his bank that he did not receive the $200 Zelle transfer that our sender had tried to send to him? I am not sure I understand how a bank is supposed to conduct the investigation when its customer says, "Hey my brother sent me $200 through Zelle but I didn't receive it." How would the receiving bank have any way of knowing that a Zelle transaction was initiated to be sent TO its customer FROM a non-customer in order to say, "Yes, I can see that the Zelle transaction never came through so here's $200 final credit for your Reg E error claim."???

I guess ultimately what is not making sense to me is that I do not see how the receiver's bank can investigate and correct the Zelle transaction error on their end so they cannot end up making the receiver whole. But if the sender does not have any "error" rights to get his $200 back to make himself whole....then what happens to the funds that never make it to the intended recipient?

Has anyone had this type of error with Zelle transactions? The sender has all of the correct information in the payment instruction. The sender's bank queue's it up as intended. But the recipient never receives the money. Is this not a similar concept as a Bill Payment transaction? Our customer provides correct Bill Payment instructions. Bank sends the correct ACH payment instructions, but the intended payee never receives the funds. Doesn't our customer have a valid Reg E Claim that the payee never received the payment? I understand that our investigation may be limited to just proof to the customer the Bank correctly sent an ACH payment instruction for the correct amount to the correct recipient and that we do not know why their bank did not post the ACH credit, but our customer still would have a Reg E Claim, correct?

My bank is telling me that a Zelle transaction that does not go through is not a Reg E claim as long as the correct amount of money is debited/posted to our customer's account and that does not make logical sense to me.

And it does not make logical sense to me that the recipient could just say to his bank, "Hey, my pal, Steve, said he sent me 200 bucks and I never got it so I want to make Reg E claim." I do not understand how we could even process such a claim?

I am curious to know if the recipient doesn't receive the funds - when the transfer 'expires' (according to Zelle this is 14 days) will the sender receive the funds back?

The receiver goes to his bank and files Reg E. That may be where the error occurred. Your consumer requested a transfer of $200 and it happened as instructed. The receiving bank needs to find the money and it may enlist your bank and Zelle to do that, but it isn't your problem.

The receiving bank needs to ensure the funds went to the correct account. If not, why. The sending info was all correct? I don't know how it gets traced, but there has to be a way to see where the funds went and why they didn't get to where they were instructed.

Okay everyone....thank you all so much for your input. I am glad to hear that this is covered by Reg E - it's just that it is the receiver who did not receive the funds that needs to raise the Reg E claim.

And this was actually a Zelle transaction between two of our customers and we were never able to determine how the funds were debited from our sender's account but were never credited to our receiver's account. We ultimately gave the sender back the money, but my concern is that I was told that this entire scenario was not even covered by Reg E because there was "no error". Well, obviously there was SOME error because the transaction was not completed as intended!!

But I take all of your points and thank you all again for the dialogue - if anyone who reads this thread has any other anecdotal stories about Zelle "errors" - not fraud, that part is relatively easy - I'd appreciate your reaching out.

Just to extend this discussion a bit -- If your bank has an agreement with Zelle that allows the bank to initiate Zelle transfers for your customers, there ought to be something in the agreement or the Zelle operations manuals that explains what's supposed to happen and who needs to do what when something (apparently) goes sideways.

Zelle can't have just set up its network without ways to trace such messes.

Agreed, John. That $200 went somewhere and auditors from Zelle or wherever should want to know. That could be a huge control issue. Did the funds revert to the sender after 14 days or some period, can the bank debit those or intercept them in this case to cover the would be loss, was the transfer refused somehow by the recipient or somewhere along the chain and could that have been BSA related? For the sake of future issues, there should be some answers available or Zelle could prosper at banks expense.

Thank you, John and Andy, for the additional considerations and great questions for me to follow up with the BL.

The most recent CFPB Supervisory Insights issue addresses this issue...

2.3.1 Regulation E error resolution for misdirected payments
Supervision conducted examinations of institutions in connection with the provision of personto-
person digital payment network services. Regulation E defines the term “error” to include,
among other things, “[a]n incorrect electronic fund transfer to or from the consumer’s
account.”12
Regulation E requires institutions to investigate promptly and determine whether
an error occurred.13
Examiners found that, in certain cases, due to inaccurate or outdated
information in the digital payment network directory, consumers’ electronic fund transfers
(EFTs) were misdirected to unintended recipients, even though the consumer provided the
correct identifying token information for the recipient, i.e., the recipient’s current and accurate
phone number or email address. These misdirected transfers are referred to as “token errors.”
Token errors are incorrect EFTs because the funds are not transferred to the correct account.14
Examiners found that institutions violated Regulation E by failing to determine that token
errors constituted “incorrect” EFTs under Regulation E.
Additionally, institutions violated Regulation E by failing to conduct reasonable error
investigations when the institutions received error notices from consumers that alleged that the
consumers had sent funds via a person-to-person payment network, but that the intended
recipients had not received the funds.15
The institutions reviewed only whether they processed
the transactions in accordance with the sender’s payment instructions and not whether the
transfer went to an unintended recipient due to a token error. The institutions did not consider
relevant information in their own records, or information that they reasonably could obtain
during their investigation, to consider whether the consumer’s error notice constituted an error
under Regulation E.
These violations caused monetary harm to consumers. As a result of these findings, the
institutions are revising their policies and procedures, are conducting lookbacks, and will
provide remediation to injured consumers.

Someone define for me "inaccurate or outdated information in the digital payment network directory." Is that the banks system because it recycled an account number, or is it the consumer input something incorrectly even though they had the correct phone number or email for the person? In the case of the former, I'm in agreement, but in the case of the latter, I disagree that the bank should be responsible. If the bank misdirected the funds that's on the bank. But if the bank put the funds in the correctly identified account that the sender typed incorrectly, how can that be an error?

The CFPB dropped a new set of Reg. E FAQ along the same lines earlier this week. These FAQ and the Supervisory Highlights are hideous in many respects, starting with the idea that CFPB should not be engaged in rulemaking through FAQ. These issues should be addressed in Official Staff Comments that are subject to notice and comment rulemaking. That would give the CFPB the opportunity to receive feedback from people that actually know what they are talking about, including how P2P payments work.

The FAQ are riddled with generalities and assumptions that cannot be universally applied. They assume that a phone number or email address is a "token" for the recipient's account number, which may or may not be the case. They also ignore the role of the P2P intermediary in the transaction, and how the funds "travel" between the consumer's bank account and the recipient's bank account. That includes consideration of what "rails" the transfer(s) ride on, and what intermediate stops are made on the way.

Analysis of these issues under Reg. E (which has essentially the same provisions that existed before the internet) is incredibly complex and deserves far better than what CFPB has done. If a transaction is initiated through a P2P provider and the P2P provider uses the consumer's debit card number to pull money from the consumer's account, when does the "EFT" start, and when does it end?

Here's an analogy: if the consumer goes to Western Union to initiate a Western Union transfer and pays for the transfer with a debit card, is the transfer from Western Union to the recipient part of the EFT on the consumer's bank account? If Western Union sends the money to the wrong place, is that an EFT error to the consumer's account? The consumer authorized the debit card transaction payable to Western Union in the amount and on the date that the transfer occurred. The fact that Western Union sent the money to the wrong place is not an EFT error on the bank account. It's a quality/delivery of goods/services issue under the Visa/MC rules but not an EFT error for the FI holding the account. Some (arguably many) P2P transactions may be analogous to this. But the CFPB can't be bothered to engage in this analysis and certainly can't be put to the trouble of doing rulemaking to actually provide reliable legal rules adopted with due process.

This is the interpretation that grabbed me:

"However, an ACH agreement combined with another agreement to process payment transfers – such as an ACH agreement under which members specifically agree to honor each other's debit cards – is an “agreement,” and thus section 1005.14 does not apply."

Does this mean if you have an ACH agreement and are part of the same card association that the exemptions in 1005.14 don't apply? Won't that remove the bulk of exemptions?

No, it means the CFPB doesn't understand how these transfers are often completed without any agreement between the P2P service provider and and the bank holding the customer's funds.

There was a discussion in the private forums a few months ago where a CFPB lawyer was discussing 1005.14 and the CFPB lawyer made the comment that if a bank has a contract to issue Mastercard or Visa cards and a P2P provider has a contract to accept Mastercard or Visa cards, then the Bank has a contract with the P2P with the P2P provider for the purposes of 1005.14. I completely disagree with that interpretation, but thta FAQ essentially puts us on notice that if there is a debit card transaction from a third party provider, we're on the hook for investigating it even if it was the third party provider's access device that was compromised.

The "narrow" exception the CFPB references would be if I authorized a debit from my account to the P2P provider and then held the funds in a moble wallet and the unauthorize charge impacted the funds in the mobile wallet.

Of course, the most recent regulatory agenda from the Bureau puts any progress on an overhaul of Reg E to bring it close to current reality on the "no action" list. It will be interesting to see if Chopra gives the review any life.

I am more concerned about the CFPB's view of what constitutes an "error" or an "unauthorized transaction" than I am about the investigation obligation. As John notes, the CFPB's view is based on a stunning lack of understanding about the way these payments happen. It's also worth noting that the Visa and MC rules expressly provide that they do not create a contractual relationship between issuer and merchant. Maybe that's not dispositive, but the CFPB should at least acknowledge it and say why they think there's a contract between issuer and merchant in spite of what the only contract documents (between issuer and Visa/MC and between merchant and Visa/MC) actually say.

Brian, this is what I read the new FAQs as saying as well.

So is it correct based on these FAQs that if a customer claims someone used their Paypal credentials to send a payment the bank would be required to investigate? Also does this also cover Target debit card transactions?

Think of the phone as the debit card. I get your debit card and use it, it's unauthorized. I get your phone and use it, it's unauthorized. Yes the bank has to review it.

I don't know the ins and outs of a Target card. Is there an agreement, even loosely between the bank and Target? I'd want to review the agreement with the consumer, but under the philosophy that Target and the bank both accept V/MC, that can be an agreement. I'd also want to see if Target fits the definition of a FI.

So even though the credentials that were used were not issued by us it would be a error under Reg E for us to investigate?

2005.14 has the tests and it is important to consider the CFPB's purpose - protect consumers. IMHO the CFPB took the easy road and said give it (responsibility) to the banks. They looked at 2005.14 and said "an agreement with a common credit card constitutes an agreement for .14" so if you do not have a clear exception, the claim will fall to you. Many state AGs have complained about the poor customer service from P2Ps to the CFPB and I just feel they saw a short cut here. I still do not understand how each entity following credit card rules pertains to these transfers unless those credit card rules could lay the liability one way or the other. And they cannot supersede Reg E. The P2P should shoulder the liability when it goes thru the P2Ps systems and they have the trail and the info. But that wasn't what came from the FAQs.

It is important to note that a Compliance Guide does not have the force of law. The FAQs are a Compliance Guide. However, if the bank is faulted for claims handling and there is any question, the CFPB will opine, and they have already, so it's not the law, it didn't go thru an ANPR process, but it might as well be the law. If this is to be changed it'll have to come from Congress or a new CFPB administration.

At the end of the day, the consumer must be protected. Banks are easier to manage than P2Ps. I believe that is Reg E Claims Math.

The Target does is not a V/MC branded card. Target issues a "decoupled debit card" to allow shoppers to use the card exclusively at Target. Instead of routing the transactions through a debit card network, the customer provides Target their routing number and checking account number and Target routes the transactions through NACHA, thus saving Target on the interchange fees. The risk to target is that unlike V/MC transactions, ACH transactions can be returned NSF.

Similar to V/MC, the CFPB is going to argue that since both Target and the bank have agreements with NACHA for ACH transactions, the bank will have an obligation to investigate a claim. What the CFPB doesn't understand is that if the Bank returns Target Card transactions as unauthorized due to the card being stolen, the Bank will also place a block on future Target ACH debits so that when the customer gets their new Target Card, the Bank will return the legitimate transactions as well because the Bank won't be able to tell the difference between the fraudulent ACH debits and the legitimate ACH debits.

I'm multitasking as I write this, but I do recall the FAQs indicated that an ACH agreement alone (with a P2P) wasn't sufficient to eliminate the 1005.14 (and I've no idea why I used 2005 above other than it's Monday) exception. But because a P2P and a bank each had V/MC agreements that did qualify for the exception. I would maintain that Target also accepts V/MC (I assume - I don't shop there) and the FAQs were not concerned that V/MC was involved in the transaction in question. It never said nor insinuated that was a condition. The fact that each had an agreement with V/MC was sufficient.

I'm already hearing bankers comment about the increase in claims. Are y'all seeing that yet?

This is the quote from the FAQs that Andy references.

In narrow circumstances, a financial institution can also be considered a “service provider” under Regulation E. A financial institution who provides EFT services to a consumer but does not hold the consumer’s account is a service provider under Regulation E if the financial institution: (1) issues an access device that the consumer can use to access the account and (2) no agreement exists between the access device-issuing financial institution and the account-holding financial institution. 12 CFR 1005.14(a). The automated clearing house (ACH) rules alone do not generally constitute an agreement for purposes of whether a financial institution meets the definition of “service provider” under Regulation E. However, an ACH agreement combined with another agreement to process payment transfers – such as an ACH agreement under which members specifically agree to honor each other's debit cards – is an “agreement,” and thus section 1005.14 does not apply. Comment 14(a)-2.