I would not expect the sender to filter out punctuation that is common to names, which to me would be apostrophes and hyphens. Those are characters many people (including yours truly!) have in their name and I think a receiver should be able to handle.
That said, I don't think carriers/receivers should be expected to handle special characters NOT native to names, such as " @ # $ ~ etc.
Instead of allowing for this to be open to sending/receiver preference and opinion, should we instead look to update the definition of what's considered valid for name fields to eliminate some of the gray (and therefore variation from carrier to carrier?). So for example, refine the definition for name fields to specifically state that alpha characters plus apostrophes and hyphens are all valid as part of the standard?
------------------------------
Timothy O'Connor MBA
AVP, Partner Integration
Voya Financial, Inc.
Minneapolis MN
15153391916
------------------------------
Original Message:
Sent: 08-30-2022 14:31
From: Lyle Griffin
Subject: Special characters in employee and dependent names
A carrier accepting LDExBEM payloads from us recently rejected one of the employees in an LDExBEM payload the first name of a dependent contained an apostrophe ("Kai'lyn"). In working to resolve the issue, our client service team requested that we add a parameter to our LDExBEM extract to filter out special characters. I am inclined to reject this request as a defect in the carrier's LDExBEM reader, but I'm interested in other companies' opinions on this subject. Should a tech partner (Sender) be expected, upon request, to filter out certain punctuation characters from names, or should the the recipient be expected to handle this?
And if tech partners (Senders) are expected to do this, should it be noted anywhere in the Coding Supplement? How about in LDExBCM (configuration management) payloads?
#LDEx-BEM
------------------------------
Lyle Griffin
President
Selerix Systems, Inc.
McKinney TX
2145025573
------------------------------