Jump to content

employees "refusing to share SSN"


Recommended Posts

We're taking over a plan with deferrals and SHM only, and the sponsor is refusing to provide us with the SSN of participants who are not deferring.  They initially didn't want to give us ANY data on them, saying that we didn't need it (sigh), but they are really digging their heels in with the SSNs.  "We've asked the employees, and they don't want us to provide them".

Is there an argument that we MUST get them?  Obviously, we need some kind of entry to put into our pension software... but I suppose that could be a dummy number.  I don't like the sound of that.

I've outlined the main reasons that we would need the SSN (consistency in tracking, possible corrections, possible use of fund platform notice distribution services, it's just What It Is), but I have to admit that if I was an obstinate employer, they aren't exactly convincing that there's nothing a specific kind of random identifier number couldn't handle just as well.

Any suggestions? Thanks.

Link to comment
Share on other sites

If a worker has no elective deferral, no matching contribution, no account balance, and otherwise could not be the distributee of a distribution to be tax-reported, there might be no current need for her taxpayer identification number (whether SSN or ITIN).

Not only in retirement plan services but also in many aspects of commerce, we should want to lessen overuse of Social Security Numbers.

But many of us have little or no power to make, or even influence, those business choices.

AlbanyConsultant, while the response might be disappointing to you and frustrating to your new client and its workers, it’s fair for a service provider to set terms under which it is willing or unwilling to provide its services.

Even for a billion-dollar plan, sometimes a service provider has no better explanation than “that’s just the only way we do the service.”

If your or the recordkeeper’s service includes a feature for an eligible employee to submit her “enrollment” and elective-deferral instruction electronically to the service provider (rather than to the employer), consider explaining, if truthful, that not having a taxpayer identification number already on record could deprive an employee of her opportunity to use the electronic-enrollment feature. A participant who has no elective deferral today might want one tomorrow. And some employers and employees prefer an electronic enrollment over a paper enrollment.

Peter Gulia PC

Fiduciary Guidance Counsel

Philadelphia, Pennsylvania

215-732-1552

Peter@FiduciaryGuidanceCounsel.com

Link to comment
Share on other sites

There are implications when managing cybersecurity and PII meets legacy retirement software. 

HR, payroll and retirement systems all need to have a unique identifier for each person in their system.  It was a matter of convenience that SSNs could fill that roll but we now live in a world where knowing a person's SSN makes them vulnerable to identify theft.

In the retirement world, SSNs are required only when we need to report amounts leaving a plan (e.g., 1099R, annuity purchase, ...) or reporting terminated vested individuals on Form 8955-SSA.

The challenge for getting HR, payroll and retirement to work optimally is to share the same unique identifier for each person across all systems.  When we work with a client with a policy that SSNs cannot be used a unique identifies, then we ask for the client preferably to provide the identifier that they use within their HR or payroll systems.

We have had instances where a client will not share this information which requires us to build our own unique identifier for each person that works within the constraints of the field length for the person's record key within our system.  It helps that the record key is treated as an alphanumeric field versus a numeric-only field.  When we do need to capture an SSN, is it stored in an available "other" field.  We maintain a table of record keys and SSNs that allow to cross-reference identifiers when needed.  We also run edits to confirm that all record keys are unique.

From what I have seen is many of the large institutional recordkeeping systems use a similar approach where the systems builds its own unique identifier for each person in a plan.  This also allows them to be able to report to a participant if that participant has an account in another plan that is recordkept on the system.  (This happens relatively often in major metropolitan areas.)

My suggestion is to engage the client in a conversation about the need for a unique identifier to track non-financial information like service dates, birth dates, compensation and hours of service to be able to perform compliance testing  required for operate the plan.  Make them aware of what is at stake (ultimately plan qualification, but more likely avoidance of costly corrections) and ask them to work with you to gather the necessary data for all employees.

Good luck!

Link to comment
Share on other sites

How large is the group?  if you are concerned about "matching" non-participant records with someone who later (might) become a participant, it may be reasonable for the service provider to establish a fee for the more difficult (perhaps, more manual) task.  IMHO, it's not unreasonable for the plan sponsor to be protective of their employees' private information in this context.

I'm a retirement actuary. Nothing about my comments is intended or should be construed as investment, tax, legal or accounting advice. Occasionally, but not all the time, it might be reasonable to interpret my comments as actuarial or consulting advice.

Link to comment
Share on other sites

9 hours ago, QDROphile said:

Who provides the Forms 1099-R and where does that person get the SSNs?

These people do not (as of now) have an account balance, so there won't be any 1099-R.  If they do decide to defer, they would have to provide the SSN to the investment company to set up an account.  They won't get an option at that point.  So that solves the 1099-R issue.

 

2 hours ago, Peter Gulia said:

Not only in retirement plan services but also in many aspects of commerce, we should want to lessen overuse of Social Security Numbers.

But many of us have little or no power to make, or even influence, those business choices.

AlbanyConsultant, while the response might be disappointing to you and frustrating to your new client and its workers, it’s fair for a service provider to set terms under which it is willing or unwilling to provide its services.

Even for a billion-dollar plan, sometimes a service provider has no better explanation than “that’s just the only way we do the service.”

If your or the recordkeeper’s service includes a feature for an eligible employee to submit her “enrollment” and elective-deferral instruction electronically to the service provider (rather than to the employer), consider explaining, if truthful, that not having a taxpayer identification number already on record could deprive an employee of her opportunity to use the electronic-enrollment feature. A participant who has no elective deferral today might want one tomorrow. And some employers and employees prefer an electronic enrollment over a paper enrollment.

I certainly understand the plan sponsor's desire to try and keep private information private.  But you can't let the inmates run the asylum.  The employer has to be able to make certain decisions without input from the employees.  Should they make the decision to share PII carefully?  Of course - if seeing our security protocols would ease their minds, I have no problem sharing those.

 

26 minutes ago, david rigby said:

How large is the group?  if you are concerned about "matching" non-participant records with someone who later (might) become a participant, it may be reasonable for the service provider to establish a fee for the more difficult (perhaps, more manual) task.  IMHO, it's not unreasonable for the plan sponsor to be protective of their employees' private information in this context.

For the ~15 employees they have (though I don't know about turnover), it doesn't seem like it would be impossible to agree on a separate identification number and apply that.  I like the idea of suggesting it as an additional manual task that requires a small charge.

 

 

2 hours ago, Paul I said:

The challenge for getting HR, payroll and retirement to work optimally is to share the same unique identifier for each person across all systems.  When we work with a client with a policy that SSNs cannot be used a unique identifies, then we ask for the client preferably to provide the identifier that they use within their HR or payroll systems.

We have had instances where a client will not share this information which requires us to build our own unique identifier for each person that works within the constraints of the field length for the person's record key within our system.  It helps that the record key is treated as an alphanumeric field versus a numeric-only field.  When we do need to capture an SSN, is it stored in an available "other" field.  We maintain a table of record keys and SSNs that allow to cross-reference identifiers when needed.  We also run edits to confirm that all record keys are unique.

From what I have seen is many of the large institutional recordkeeping systems use a similar approach where the systems builds its own unique identifier for each person in a plan.  This also allows them to be able to report to a participant if that participant has an account in another plan that is recordkept on the system.  (This happens relatively often in major metropolitan areas.)

My suggestion is to engage the client in a conversation about the need for a unique identifier to track non-financial information like service dates, birth dates, compensation and hours of service to be able to perform compliance testing  required for operate the plan.  Make them aware of what is at stake (ultimately plan qualification, but more likely avoidance of costly corrections) and ask them to work with you to gather the necessary data for all employees.

Thanks.  All this is reasonable.  And I'm not trying to be unreasonable about it.

So, ultimately, there is no need for SSN to be used as a unique identifier as long as there is a different unique identifier and its only purpose is in our system.  It has just become a convenience (as described in this humorous explanatory video here).

Link to comment
Share on other sites

If they have no money in the plan, you don't really "need" an SSN. But you can feel free to charge them for the extra work you have to do to create unique employee identifiers in your system and the trouble you'll need to go through should they start deferring or receive an employer allocation in straightening out the data when you invariably wind up with two nearly identical sets of data for Joe Smith hire 1/1/2020 with a birth date of 1/1/2000 and two different identification numbers.

Link to comment
Share on other sites

We have a few clients that refuse to give us SSNs unless we are doing distribution work. 

They however all agreed to give us an Employee ID number that was unique to just that person with each census across time.  They were responsible to assign the number and make sure it is only used for one person. We loaded it to the SSN field in the software.

In the end the reason you want SSN is you need a unique and consistent number to match up data over time for and from the client.  As long as they can give you a number that does that I am not sure why you should keep objecting.

 

Link to comment
Share on other sites

On 2/23/2024 at 1:50 PM, ESOP Guy said:

We have a few clients that refuse to give us SSNs unless we are doing distribution work. 

They however all agreed to give us an Employee ID number that was unique to just that person with each census across time.  They were responsible to assign the number and make sure it is only used for one person. We loaded it to the SSN field in the software.

In the end the reason you want SSN is you need a unique and consistent number to match up data over time for and from the client.  As long as they can give you a number that does that I am not sure why you should keep objecting.

 

I've come around to the idea that we don't NEED the actual SSN for participants with no account balance.  What I am concerned about is (a) the client remembering to give us SSN for those with balances and the correct consistent unique identifier for the others (since that will take manual work and review), and (b) the plan sponsor letting the individual employees make the choice on an individual level (I don't want participants to start thinking they have control over the administration of the plan).

Mainly, I don't trust plan sponsors, and I dislike participants.  Oh, and I distrust the IRS/DOL.  Other than that, I love this job. LOL

Link to comment
Share on other sites

8 hours ago, AlbanyConsultant said:

I've come around to the idea that we don't NEED the actual SSN for participants with no account balance.  What I am concerned about is (a) the client remembering to give us SSN for those with balances and the correct consistent unique identifier for the others (since that will take manual work and review), and (b) the plan sponsor letting the individual employees make the choice on an individual level (I don't want participants to start thinking they have control over the administration of the plan).

Mainly, I don't trust plan sponsors, and I dislike participants.  Oh, and I distrust the IRS/DOL.  Other than that, I love this job. LOL

Personally the times we have done used an employee number it was an all or nothing.   Everyone came with the EE Num and when it was distribution time they had to give us SSN or people didn't get paid.  

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...