Home / Blogs

Broken Policies

Laura Atkins

As an email policy wonk, I think a lot about how specific policy implementations can go wrong. Sure, every policy can go wrong, or not fit a common case. A lot of people only write polices that address common cases and don't worry about the rarer cases. The problem is there are some rare cases that may cause significant harm and those cases should be addressed.

Consumerist has a case up about email policy gone wrong with a clear path to harm but no policy for handling the issue. There are a couple places I see where this policy hole can be fixed.

Chase Bank does no verification when they collect email addresses, which results in them sending email to a person who does not have an account with Chase. This is not an ideal situation for anyone. Chase is revealing private financial information to an outside party, the actual bank customer is not getting their information and someone is getting email about money that's not theirs.

In terms of policy for institutions handling sensitive personal information, I would always recommend implementing a verification step. This is mail that people want so they should confirm it. It's also mail that really should be not going to 3rd parties.

Chase does not implement any verification step for email. This isn't a fatal problem, as long as there is some process in place to get feedback and then correct the issue.

Unfortunately, Chase's policies failed here, too. Chase requires an account number to speak to a representative about any issues. In this case, the email recipient does not have an account number. All of Chase's contact channels rely on an account number: no account number, no talking to a human.

In terms of overall policy Chase is hoping here is that, at some point, their actual customer will notice they're not getting email and call in and attempt to troubleshoot the problem with Chase reps. I'm willing to bet, though, that their tier 1 people don't have the training or information needed to troubleshoot this problem. I expect they're going to read the script that says, "We sent you the mail, it must be a problem on your end. Have a nice day."

Chase, and other bank analogues that require an account number, that do not verify email addresses should not require account numbers to talk to someone about the mail they are receiving. Why? Because although it's reasonably rare that the mail is going to the wrong party, the potential harm to the bank's customer is very high. This danger to customers means the bank should invest in a support pathway that allows non-customers to call, or write, to report misdirected email.

If Chase were my customer, I'd recommend adding a button to the email that says "receiving this mail in error, report here." Make this a simple form that the recipient can fill out, two boxes one for email address and one optional one for "reason". Once the bank has the report, they can stop the misdirected email and attempt to contact the customer through another channel. I'd also recommend that customers confirm any new address they add to the account in the future.

I know the bank thinks that by requiring an account number they are protecting their customers. Unfortunately, they're failing to address a rare but potentially harmful case. Sadly, I expect even after this, they will still fail to implement any changes that will stop this from happening in the future.

By Laura Atkins, Founding partner of anti-spam consultancy & software firm Word to the Wise
Follow CircleID on
SHARE THIS POST

If you are pressed for time ...

... this is for you. More and more professionals are choosing to publish critical posts on CircleID from all corners of the Internet industry. If you find it hard to keep up daily, consider subscribing to our weekly digest. We will provide you a convenient summary report once a week sent directly to your inbox. It's a quick and easy read.

I make a point of reading CircleID. There is no getting around the utility of knowing what thoughtful people are thinking and saying about our industry.

Vinton Cerf, Co-designer of the TCP/IP Protocols & the Architecture of the Internet

Share your comments

To post comments, please login or create an account.

Related

Topics

Whois

Sponsored byWhoisXML API

New TLDs

Sponsored byAfilias

Domain Names

Sponsored byVerisign

Cybercrime

Sponsored byThreat Intelligence Platform

IP Addressing

Sponsored byAvenue4 LLC

DNS Security

Sponsored byAfilias

Cybersecurity

Sponsored byVerisign