We have a several districts where their local bank (US Bank) is requiring that their "ID Designator" be changed from "1" to a "2". The bank has the district transfer the file over to the PC, editing it via Notepad, changing the "1" that appears before their EIN, to a "2" and then uploading it to the bank for processing.The DIRDEP/DIRMNT program only allows a 1, 3 or 9 and no "2"...is there a way other than physically modifying the flat file, to have the "2" instead of the "1"?
Thanks in advance,
There is a way you can "*****1" this, but it's really not a good solution. There is a datatrieve domain for this record: DIRECT_DEPOSIT_MST. The field in question is named ID_DESIGNATOR. Datatrieve will allow you to change this field to a 2 and this change would be picked up when PAYDIR is executed and the ACH tape file is created.
However, the main issue with doing this is you are using datatreive to circumvent the screen validation and inserting data that is invalid from the systems perspective. This is never a good idea. From what I can tell for this specific example the main issue you would run into would be you would never be able to modify this record in DIRDEP/DIRMNT without changing the value of "2" to something the system sees as valid (1,3, or 9).
The real issue here is that I think we may have our validation incorrect. I took a brief skim through the 2013 NACHA regulations and did not see a validation stating this needs to be a 1, 3, or 9. My guess is in the past this was probably the case, but NACHA loosened the requirements on this field and allows various entities to specify their own identification designation and number.
Apparently most entities must just use the EIN as this is the first report we have had of this issue. US Bank must be using some custom in house identifier or something. I would be curious to know what they are actually using as the identifier if you have that info. Don't post the actual ID here as that would be sensitive, but post or send me an e-mail with a summary of what the value they are using represents.
So, assuming a closer look at the NACHA requirements confirms my initial analysis we really need to update the validation on DIRDEP/DIRMNT to allow other values to be entered.
I have created USPSV-1635 for this change and will prioritize it, so it can be completed as soon as possible.