US banks that can send PGP/MIME e-mail

[Robert J. Hansen]

On 02/25/2013 03:20 PM, Anonymous Remailer (austria) wrote:
> Where does this idea that a business case must be recognized by all
> suppliers for an entire industry in a whole country before it "works"?

No one, but your statement seemed to be a severe overgeneralization.
Declaring that something works "in Germany" has a strong implication of
it working throughout *the whole of* Germany.  If your intent was
instead to say, "Why does it work for these specific banks?", then I
have no objection to that and I think it's a very reasonable question.

> A business case can be viable if there are *zero* implementations,

Like perpetual motion machines, business cases are judged by how well
they work in the real world.

>   1) First of all, you're assuming that the feature is
>      officially supported.  A bank need not support anything,
>      officially.

The discussion is about banks that *send statements via encrypted
email*.  If the bank is doing this then it's officially supporting it.

>   2) You're assuming that official support implies unlimited resources
>      must be allocated to every call.

No, I'm not.  At some point any business will declare a customer to be
too much trouble for the amount of profit made from that person and will
seek to alter or terminate the business relationship.  This does not
change the fact that people will still seek technical support, and that
technical support costs money.

And if the bank is officially supporting sending customers bank
statements via encrypted email, then yes, the bank does need to offer
technical support or else the bank will soon be losing customers.

>   3) An hour of tech support costs the bank about $5-10 for the cheap
>      labor they've outsourced it to India.  Perhaps another $10 if the
>      Indian call center has operators who have been trained to lose
>      their accent and sound American.

Having seen the balance sheets for tech support costs for a couple of
Fortune 50 firms, I can tell you that you're off by an order of
magnitude.  Unfortunately, I'm bound by nondisclosure agreements and
can't really say more than that.  $100 for an hourlong session is in the
right ballpark for the firms I have firsthand experience with.

To give you an idea of how the accounting is done, though, labor costs
are the least of the concern.  Another major concern is, "What if the
customer gets so frustrated with the problem that the customer stops
doing business with us?"  If 1% of tech support calls result in losing a
customer, and the average lost customer would've resulted in $10,000 of
profit over the course of that customer's relationship with the
business, then the amortized cost of a tech support call just jumped to
$100... right there... based on nothing more than the cost of the
customer's frustration.

You cannot measure the cost of a tech support call solely by the cost of
the labor involved.  The labor involved is insignificant: it's so minute
it's practically considered accounting error.  The real costs come
elsewhere, and they accrue the instant the tech support call is placed.

> Then you would choose to be a dime-a-dozen bank, and compete with tens
> of thousands of banks for 1/10000th of 99% of the market, which is
> obviously not as profitable as taking the other 1% in whole.

This assumes the 0.1% that uses OpenPGP provides per-customer revenue
comparable to that of the 99.9%.  This is probably not true: you're
talking about such a small selection of users that their profile will
probably be quite idiosyncratic compared to the community at large.

>> Honestly, if I was advising a consumer bank about this, I'd tell them to
>> avoid OpenPGP.  I don't see the business case for it.  And until you can
>> show me either (a) radical improvements in ease-of-use,
> 
> Partner with hushmail.

So your "solution" involves telling customers, "we will support your
request to use OpenPGP for sending encrypted bank statements, but only
if you agree to use Hushmail for a mail provider, even though they have
a track record of turning cleartext copies of email over to legal
authorities"? [1]

[1] http://www.wired.com/threatlevel/2007/11/encrypted-e-mai/

>> (b) radical reductions in technical support costs,
> 
> Don't offer unlimited support.

You seem to think the problem is unlimited support.  It's not.  The
problem is the instant *any* support is offered it's a minimum $100
charge (under the model I presented above, where each call has a 1%
chance of terminating a business relationship that would've been worth
$10,000 over its lifetime).

You can reduce the price of offering technical support or reduce the
rate at which technical support is needed.  Capping support will do
nothing to mitigate the problem, because labor costs -- the thing you're
proposing to cap -- are not the problem.

> The demand need not be "explosive" if you're the only one (or one of
> very few) supplying the demand.

Nobody ever made a fortune by catering to a small and stagnant market.
OpenPGP adoption has, on the whole, badly stagnated.  (Email itself is
also stagnating, which is far worse.)

In the quite-excellent film _Other People's Money_, an entrepreneur has
this to say on the subject:

	"You know the surest way to go broke?  Keep getting an
	 increasing share of a shrinking market.  Down the tubes.
	 Slow but sure.  You know, at one time there must've been
	 dozens of companies making buggy whips.  I'll bet the
	 last company around was the one that made the best
	 Goddamned buggy whip you ever saw.  Now, how would you
	 have liked to have been a stockholder in that company?"

Email is already stagnating -- the next generation of customers
(teenagers and college students) associate email as a decrepit
technology that was cool back in their parents' day.  The next
generation of customers wants HTML5 and smartphone apps.

The number of people who want balances emailed to them is not growing,
it's *shrinking*.  The number of people who want those statements
encrypted with OpenPGP is, at best, stagnating.

If you like, I encourage you to supply that demand.  I think you'll
quickly discover you're the buggy whip manufacturer in the
entrepreneur's story.

> You've failed to make a convincing case for why a business case
> already proven to work in Germany would fail in the US.

A business case which has already shown itself to work *for one bank*.
Without knowing details of this bank's economic niche, its customer
demographics, its technological infrastructure, the choices it made
which led it to its current point, it is impossible to make any kind of
pronouncements about whether that same plan would work in the United
States.  You can't say it would.  You can't say it wouldn't.  You simply
don't have the data to make any argument one way or another.