

The facts about ADP and Zenefits: Response to the claims made by Zenefits [pdf] - cgoodmac
http://www.adp.com/zenefits/downloads/The-Facts-About-ADP-and-Zenefits.pdf
Disclosure: I work at a competitor to both - posting this because I find it generally interesting from a data security and integrations perspective.
======
phantom_oracle
Just swap this story around and change it to:

 _Big corp. starts illegally stealing data through improper means and not
following T &C of small-funded startup_

and there would be an uproar.

All those fluff tech-sites that treat Apples new Iphone with incremental
changes as "big news" would suddenly have months of juicy news to bash the big
corp to the point where their bigger media-parent companies would follow suit
and damage the big corp indefinitely.

Maybe folks should just call "a spade a spade" here.

The startup violated the T&C of ADP and whether or not ADP is 100% honest of
the server-volume from this company, the startup still committed an illegal
action.

You can "disrupt" industries all you like, but when you break explicit
contracts, you can't go crying on social media about it and expect things to
work out for you.

As far as PR goes, ADP won with this line:

"We’re willing to work with our clients who use Zenefits, and with Zenefits
directly, to find a solution that fulfills our clients’ needs and protects
their data."

~~~
devicenull
> The startup violated the T&C of ADP

Here's a fun question... Did Zenefits ever agree to the TOS?

~~~
mbesto
> _By using the Zenefits Service, you hereby grant us permission to access
> your Account Information maintained by identified third parties, and make
> changes to this information as directed by you, on your behalf as your
> agent. When you use the 'sync payroll' feature of the Service, you will be
> directly connected to the website or APIs for the third party you have
> identified. We will submit information including usernames and passwords
> that you provide to log you into the site. You hereby authorize and permit
> us to use and store information submitted by you (such as account passwords
> and user names) to accomplish the foregoing and to configure the Zenefits
> Service so it is compatible with the third party sites for which you submit
> your information._

So basically a user of Zenefits gives Zenefits the authority to act as an
agent on behalf of them. So, technically when Zenefits accesses the ADP site
they are legally seen as the authorized user themselves.

If I knew that a service was going to act on my behalf towards another party
and that other party wasn't happy about the way that service behaved towards
them. I might question my use of letting that service act as my agent.

Zenefits is actually pretty smart here because they can say "our users want
this, they've agreed to our ToS that says we act on their behalf".

~~~
samch
I disagree with your conclusion there. Having your clients violate the ADP TOS
(and then subsequently violating it yourself while scraping data) is clearly
not a smart move as illustrated by ADP's response.

~~~
shaaaaawn
Agreed. Zenefits took an engineering/business shortcut by scraping and using
the default 3rd party user credentials. It was only a matter of time before
this got shut off. They'll do what every other large 3rd party does, sign an
MSA of some sort, build a better integration, and pay a massive annual fee to
ADP for access. This is Financial Services

------
eitally
I'm glad they posted this. It sounds like Zenefits could get away with using a
startup mentality to work around an enterprise software/platform provider's
generally accepted architecture for integrations, if not their explicit TOS,
and was burned. Perhaps ADP will learn from this and look at it as an
opportunity, or perhaps they won't. It's not like enterprises with ADP
contracts are going to switch away from them because they can't use Zenefits
on top of it....

Integrating with ADP is easy, but like so many other enterprise
software/platform integrations, each project has to be taken independently.
Zenefits doesn't want this but ADP doesn't have any real reason to change
things.

~~~
TimSchumann
> Integrating with ADP is easy, but like so many other enterprise
> software/platform integrations, each project has to be taken independently.

How are those two statements not contradictory? Seems to me that if
integration was easy (read standardized) it would be agnostic of, not specific
to, who was integrating.

~~~
dragonwriter
"Easy" is not opposed to "time consuming and tedious". Its quite possible (and
common, IME, in programming) for things to be both _easy_ and time consuming,
tedious things that need to be done one-off for each particular implementation
because you are working with something that, for instance, resists the kind of
abstractions that would make it generalizable.

Pretty much anything for which recipe-style cookie-cutter patterns are
documented, for instance, fits this description.

~~~
eitally
Exactly this. Things like payroll integrations and benefits administration are
not obvious and straightforward at any large company. For example, even common
things like international transfers or leaves of absence can trigger manual
processes at companies that don't have software to do it for them. Integrating
with ADP is easy, but figuring out the business logic and process re-
engineering is tedious.

It's exactly things like this why I think most programmers and architects
should spend at least a year or two working in a large corporation. They'll be
exposed to all kinds of situations that just don't exist in a startup (or even
most SMBs).

------
thrillgore
This PDF has a better interface and user experience than anything else i've
ever used with ADP on it.

~~~
knodi123
seriously, you're not kidding. If ADP wants to convince me they've got
programmers I can trust, a good place to start would be by hiring a UI
designer above the age of 20 who can answer the question "what is a best
practice".

~~~
tptacek
Regardless of the qualifications of the average ADP programmer, they spend
what we in the business would refer to as "a cubic fuck-ton" on application
security. I have no idea if they get it perfectly right, but when ADP makes an
argument premised on security, I take it seriously.

~~~
lawnchair_larry
We must have seen different ADPs. The one I saw was still 1990s security all
over the place. It didn't look like they had even heard of security.

They're one of those companies that tell their enterprise customers that they
are _not allowed_ to update to a new point release of Java.

~~~
tptacek
Then yes, we have seen different ADPs.

------
MangezBien
I hate ADP with a burning passion (as a user of them across three different
companies now) but their points are totally reasonable. Zenefits looks like a
petulant child and seems to have made no good faith effort to integrate with
ADP properly.

------
shaaaaawn
It's funny watching the Zenefits response: Bring in the yComb & Celebrity
Investors (Jared Leto / Ashton Kutcher) to get public opinion on their side
via twitter #ADPeeved and a Change.org petition. So far at least on social
media there's not a lot of noise from impacted customers. Just negotiate an
MSA, pay the fee, build a proper integration and perform better Risk
Management in the future (like a $4.5B business should).

------
markbnj
It's an interesting shot back at Zenefits from ADP. I have no way to judge
ADP's claims with regard to security and the volume of requests. It would not
surprise me if they were true... or not. But I suspect the fourth row in the
table is the one that really matters.

------
scarmig
I never expected to feel sympathy for ADP. This is a pretty effective PDF.

------
cgoodmac
OP disclosure: I work at a competitor to both - posting this because I find it
generally interesting from a data security and integrations perspective.

~~~
pkaye
What do you think of the ADP claims?

~~~
cgoodmac
If ADP's claims have any truth (and I can't say if they do), it's shocking and
very bad.

Data security (SSNs, banking info) is difficult, but they're table stakes in
the payroll and benefits space (ex., how do you securely share personal
information across different benefits providers).

Honestly, my main takeaway is I'm happy our company built everything (payroll
and benefits) in-house from scratch.

We worry less about integrations issues, and it helps with security when you
have more control over everything.

It's been extremely difficult building everything from the ground up, and I've
definitely questioned our approach (more than once I said, "Why don't we just
integrate with X?"), but I think this validates the path we've taken.

This is a lesson I'm going to take away for whatever other software/service I
may end up working on.

~~~
chralieboy
> Honestly, my main takeaway is I'm happy our company built everything
> (payroll and benefits) in-house from scratch. > We worry less about
> integrations issues, and it helps with security when you have more control
> over everything.

This is not a good take away. The same could be said for rolling your own
cryptography — control + no integration — which is a really terrible idea.

This doesn't validate your approach since the problem wasn't that a third
party you were integrating with messed up your data. I understand why you
wanted to build everything in house, but this isn't an example that validates
your decision.

------
beachstartup
i posted this yesterday, but the top three reasons i didn't go with zenefits
(not that it matters because apparently they are taking over the world):

1\. sales people were pushy dickheads that implied i was wasting their time by
re-scheduling their demo due to emergency client issues, when i am their prime
audience - an overworked, underpaid, understaffed startup founder.

2\. they couldn't articulate how they integrate with my payroll service. it
was a bunch of hand waving and "trust us". unfortunately i know how technology
works and i'm not going to "trust" anyone unless they have a well defined
solution.

had i known i was supposed to give them my administrator login information, it
would have been a non-starter anyway.

3\. the fact that their business model was basically to take business from
existing insurance brokers seemed a little lame to me. why can't i just pay
for your services?

~~~
obornii
1\. OK - I agree.

2\. So - did you get mint.com to tell you how they integrated with your
bank(s) ? Did your local bank tell you, for that matter, how they did
background searches on their staff ?

3\. You clearly don't manage a company with issues like COBRA, insurance, or
payroll.

I almost didn't get past #1, but #2 and #3 were non-issues. Why? Because when
you manage a business, you have to focus on your core business: So either pay
to outsource HR (6K month, thats a salary right there), risk noncompliance
with a broker, or go with Zenefits and worry about under-the-bed monsters that
do not exist under #2-#3.

~~~
beachstartup
i think the only thing that's clear here is you don't actually run a business,
because you're pretty much wrong, or make incorrect assumptions, on every
single point.

for example: i do know the background-check procedures my bank uses on its
employees. it's in the fucking brochure they give you when you open a
commercial account.

------
MCRed
This is not the first time a YC company has "hacked" their way into success--
for example AirBnBs spamming of Craigslist users and violating Craigslists ToS
in other ways. In fact, these kinds of things come up so often I wonder if
it's not encouraged.

It's kinda balsy, though, to get client's admin ids, and then use that to go
after their data.... and then when this is cut off, to complain about it.

Especially given the entitled and, if ADP is being honest, dishonest way they
portrayed the events.

~~~
radnam
How else would you suggest a 2 person startup compete with likes of ADP? This
is client's data not ADP's data.

~~~
myblake
Zenefits is not a 2 person startup, they're worth billions of dollars, have
hundreds of millions in the bank and have several hundred employees. It's
probably better to think of them as a privately owned growth company than a
start up at this point. (Edit: here's a source
[http://techcrunch.com/2015/05/06/zenefits-rising-hrs-
hottest...](http://techcrunch.com/2015/05/06/zenefits-rising-hrs-hottest-
startup-just-raised-500-million-at-a-4-5-billion-valuation/))

------
spdustin
Wait... So was Zenefits _scraping_ ADP's RUN portal?

~~~
gvb
Apparently scraping their portal via _" access to our systems by convincing
clients to give them administrative access to our platform."_

Wow. Talk about a disaster waiting to happen.

------
slang800
> Our first priority is protecting our clients and their data.

...From themselves? If someone wants to manage their account through a 3rd
party that allegedly uses some non-standard way of accessing ADP then that's a
risk they decided to take. ADP should be figuring out a way to give Zenefits
(and any other similar companies) more secure access to their platform, not
cutting them off.

~~~
7Figures2Commas
> ADP should be figuring out a way to give Zenefits (and any other similar
> companies) more secure access to their platform, not cutting them off.

From the PDF:

 _Despite having many legitimate ways to integrate with ADP properly, Zenefits
chose an unsecure and indirect approach._

> If someone wants to manage their account through a 3rd party that allegedly
> uses some non-standard way of accessing ADP then that's a risk they decided
> to take.

From the PDF:

 _Despite Zenefits serving less than 0.25% of the clients on our system, they
had been responsible for up to 25.0% of the total user traffic (in other
words, a hundred-fold times ordinary user traffic)._

 _The Zenefits approach was not only putting excessive and unnecessary demand
on ADP’s servers, but it was pulling sensitive information, including unmasked
Social Security numbers and employee banking information, in a manner that did
not comply with ADP’s standards for data security._

It sounds like ADP did what any company, large or small, would do when faced
with a third party accessing its systems in an unauthorized and inefficient
manner.

~~~
slang800
> Despite having many legitimate ways to integrate with ADP properly, Zenefits
> chose an unsecure and indirect approach.

Do you really think Zenefits just chose this "lesser" method on a whim? I've
never met the team from Zenefits, so I can't say for certain, but if they're
not idiots then I think there's a reason why they decided not to use the
regular API. Whether that's a requirement of getting their app approved by the
ADP Marketplace, or some restriction on the data that they are able to get
through the official API - I think that there's something that ADP isn't
mentioning.

> It sounds like ADP did what any company, large or small, would do when faced
> with a third party accessing its systems in an unauthorized and inefficient
> manner.

As far as unauthorized methods go - you'd patch the hole in your security to
prevent them from getting through. Unauthorized methods of accessing your
systems shouldn't exist, and blacklisting the domain name of the third-party
isn't how you fix a security flaw. For the excessive load, they should just
implement rate limiting across their system & return a 429 when someone goes
over.

Of course, I really doubt that they were accessing ADP via a real security
flaw - they were probably just making the same requests as users are able to,
but in an automated fashion. And if that's the case then the term
"unauthorized" doesn't apply, because users are clearly authorized to make
those requests.

~~~
smackfu
> For the excessive load, they should just implement rate limiting across
> their system & return a 429 when someone goes over.

Practically, I'm not sure that would be much better for Zenefits.

~~~
slang800
I think that rate limiting might just force Zenefits to stop using whatever
contributed to the high load, and ensure that their API calls are efficient
enough. Otherwise, if they really can't do without that volume of calls, then
at least they would be locked out in the same way that everyone else is & they
couldn't really call it unfair.

------
wnevets
Hats off to ADP for responding.

------
binxbolling
Now where's the Zenefits rebuttal to this salvo? I think this story is really
interesting on a number of levels.

~~~
aaronem
They're probably too busy right now talking to their recent investors [1] to
provide one.

[1] [http://techcrunch.com/2015/05/06/zenefits-rising-hrs-
hottest...](http://techcrunch.com/2015/05/06/zenefits-rising-hrs-hottest-
startup-just-raised-500-million-at-a-4-5-billion-valuation/)

~~~
baakss
They weren't too busy to fire off the initial complaint over social media
though? Supposedly that's what prompted ADP's response, though I can't find a
link to Zenefits complaint.

------
dikaiosune
Enterprise integrations are expensive and can take a long time to get to
market. So I can see why Zenefits would have avoided doing so for as long as
possible.

Perhaps Zenefits, having using their hack-around for a while, needs to look at
a proper integration? Call ADP's bluff? If ADP is telling the truth that
they've never had conversations about service integrations with Zenefits
before, it seems like that may be a good place to start.

~~~
eitally
As someone who's team has been responsible for an enterprise integration with
ADP on more than one occasion, it's really not that hard. It's well documented
on their side, setting up data feeds is trivial if you need them, and one
everything is working it's pretty much set & forget reliability. Sure, as
mentioned in the previous thread, ADP's portal UX is horrifically dated, but
that has nothing to do with back end integration.

I think none of our integration projects had an internal cost (labor) of more
than about $20k.

~~~
seekingcharlie
I also managed an ADP integration & second this.

Their engineers were really quick to respond to us throughout the process too.

------
joshdance
Using ADP was the worst part of my week at my previous company. This PDF is
better designed than anything I ever saw from ADP. And good to know of have
more ideas about both sides of the story.

------
tw990
[http://blog.zenefits.com/adp-2/](http://blog.zenefits.com/adp-2/) ADP rolls
out Zenefits competitor hours after claiming they were not in a lawsuit.

The truth will always reveal itself! /zenefits EE

------
BrandonMarc
Other side of the story:
[https://news.ycombinator.com/item?id=9688058](https://news.ycombinator.com/item?id=9688058)

------
c-slice
Why doesn't Zenefits just become a payroll provider? Is the an enormous amount
of regulation around providing payroll services?

~~~
speby
That [currently] is not Zenefits' business model. Their entire premise is that
you can practically use any providers you want for your benefits such as
various 401K providers, various health care plans, etc., as well as any
payroll vendor. Zenefits makes its money as a broker when you choose to go
through Zenefits to get things such as payroll or benefits administration
services. But the key is that Zenefits itself is not providing the said
services. They are paid on commission or rev. share with the providers that
ultimately service Zenefits customers.

While they could become a payroll provider themselves, that isn't really their
mission. As well, it's not so trivial to write some software "over the
weekend" and have a solid payroll system. While payroll companies actually
have very little regulation (this is true, and somewhat surprising), it is
complex to build a payroll system that can accommodate all the various needs
of clients. Just to name a few things to get started: Hourly, salary, pay
cycles, 1099, fed/state/local taxes and tax codes and rates, time off
tracking, punch in/punch out, check printing and electronic deposit, paper and
electronic tax filing, tax payments, garnishments, time off tracking,
pre/post-tax deductions, worker's compensation rates, union dues, and the list
just goes on from there.

------
at-fates-hands
_" but it was pulling sensitive information, including unmasked Social
Security numbers and employee banking information"_

Did ADP just admit they keep SSN and banking information in plain text on
their servers???

~~~
CPLX
No, but they admitted you can access that information if you are logged into
an account.

If you have figured out a way to do something like print a employee's copy of
an IRS form like a W-2 or 1099 without having plaintext SSN information
involved in the process I would sure be curious to hear about it.

~~~
tzs
That raises an interesting question. Why is my SSN printed on my W-2?

Presumably I already know my SSN, so do not need the W-2 to remind me of it.

~~~
CPLX
Because the SSN is the "primary key" for pretty much all interactions with the
taxing authorities. That's why it's called a "Taxpayer Identification Number"
and so on. Sure it's a sensitive piece of info, at least to some extent, but
it's not some highly classified secret. Putting it on tax forms is sort of the
point.

~~~
tzs
Right, which is why it needs to be on everything I send to the IRS, or that my
employer (or their agents such as payroll companies) send to the IRS
concerning me.

But I don't see why it needs to be on things my employer (or their agents)
send to me. Sure, SSN is not some highly classified secret, and it is on
enough things it does not need to be on that having it on W-2 probably doesn't
noticeably cause any extra harm. I'm just curious if it actually needs to be
there.

If I'm doing my tax return on paper instead of electronically, and need to
physically attach a copy of my W-2, I can fill in the SSN field, just like I
filed in the SSN field on the top of the 1040. Having the SSN on the form
then, when it goes to the IRS makes sense so that they can match it up to the
1040 if it becomes separated from it accidentally [1].

If I'm doing my tax return electronically, the IRS uses the W-2 information
they get from my employer (or its agents) electronically. The paper W-2 is
really just to let me know the pay and withholding numbers so I can fill out
my returns.

[1] Well, maybe not. It did back in the days when they actually looked at the
physical W-2, but now I believe they get an electronic copy even if the
taxpayer is not filing electronically, and so I don't think they look at the
attached W-2. In fact, I vaguely recall the last time I filed a paper return
being told not to attach my W-2, although I'm not certain of that.

~~~
CPLX
I'm not sure that entirely makes sense. This presupposes that your name and
salary information is somehow less sensitive information than your SSN, and
ignores the fact that essentially the entire point of the form existing at all
is to document the statement "Please match SSN [X] with income [Y]" and
removing one of those two pieces of data defeats that purpose.

