CUNA Comment Letter

ACH Requirements for Social Security Number Security

July 15, 2003

Ms. Maribel Bondoc Network Services Assistant NACHA 13665 Dulles Technology Drive Suite 300 Herndon, Virginia 20171

Dear Ms. Bondoc:

The Credit Union National Association appreciates this opportunity to comment on the request for comments regarding NACHA’s request for information regarding modification of the NACHA Operating Rules (Rules) to comply with state laws that forbid the mailing of social security numbers (SSNs). Specifically, the proposal addresses the issue of whether the Rules should be amended to specifically address the inclusion of a consumer’s SSN within an automated clearing house (ACH) entry. CUNA, a national trade association, represents more than 90 percent of the nation’s 10,000 state and federal credit unions. This letter reflects the views of CUNA’s Payment Systems Subcommittee, whose chair is Terry West of VyStar Credit Union, Jacksonville, Florida.

The request for information asks for comments on various possible alternative amendments to the Rules. CUNA’s reactions to those alternatives are set forth below.

CUNA does not favor explicitly prohibiting an Originator from including a consumer’s SSN within any ACH record. Credit unions and other ACH participants use SSNs to assist in researching problems that occur with ACH entries. Receiving depository financial institutions (RDFIs) use SSNs to help identify the correct entity when multiple entities have the same name or the account number in the ACH record is wrong.

The proposed scenario explicitly prohibiting an Originator from including a consumer’s SSN within any field for which the contents of that field may be printed to the consumer’s bank account statement. While the originating depository financial institutions (ODFIs) would provide this warranty under the proposal, in actuality the ODFI does not have control over what the RDFI chooses to print on the account statement. In order for this approach to be practical, new rules indicating the ACH entry field(s) which may contain a SSN and which fields may be printed on statements would have to be developed.

In CUNA’s view, the best approach would be to require the Originator to populate an indicator field with the Entry Detail Record to indicate the presence of a consumer’s SSN within any ACH record. This option would enable RDFIs to make software changes to ensure their systems recognize the field indicator so that SSNs do not print on periodic account statements. We recognize that changing the software to accommodate this requirement could be expensive and time consuming for many credit unions and other financial institutions. Importantly, this scenario would permit all ACH participants to continue to use SSNs as backup in case they need to investigate and/or respond to inquiries related to ACH transactions. CUNA emphasizes that under this option the government must use the indicator field since the government is the largest transmitter of SSNs. From CUNA’s perspective, it would be more efficient to have a specific field for the SSN and RDFI could suppress that field. For example, it would make sense for RDFIs to suppress the Individual ID Field for member/customer statements unless the transaction involves a converted check application, such as POP (Point-of-Purchase Entry), ARC ( Accounts Receivable Check Entry) or RCK (Represented Check Entry).

We oppose the proposed option of requiring that any SSN used within any ACH record be truncated or masked in such a way that the data which appears in the ACH entry is unrecognizable as a SSN. We do not support this option because the full SSN is often relied on by institutions to research problem ACH entries. Masking or truncating this number would significantly reduce the ability of ACH participants to research ACH entry problems. In other words, this option would mean the loss of the validation benefit at RDFI level. Further, it would make the process of returning ACH items much more difficult. It may also be operationally complicated because the RFI would need the key to unmask the ACH data.

Finally, we believe the approach of explicitly prohibiting an RDFI from printing any SSN contained within an ACH entry to the consumer’s account statement is impractical. This option puts the entire onus on RDFIs to identify and suppress the printing of SSNs on account statements. However, it would be extremely difficult for the systems of RDFIs to recognize the formatting for each ODFI to ensure they do not print the SSN unless there is uniformity. We strongly feel that if this option is selected, ODFIs should be required to make any necessary program changes to enable RDFIs to recognize whether a SSN is being transmitted in an ACH record.

In addition, there may be legitimate reasons for financial institutions to print out SSNs, for example once a year to verify that the account information on the statement is valid. CUNA feels the rule ought to provide for such exceptions.

Thank you for the opportunity to share our comments. If you have any further questions, please contact Mary Dunn ( mdunn@cuna.com) or Catherine Orr (corr@cuna.com) at our e-mail addresses or at (202) 638-5777.

Sincerely,

Mary Mitchell Dunn
Associate General Counsel

Catherine Orr
Senior Regulatory Counsel