Customer Validation on Inbound Collection Call 684



  • We are developing a collections software package for multiple clients, and included a provision for customer validation information. We are providing a field to store a secret code word for validation and a hint if you forget. Most places use the last four digits of the customer’s SSN or the mother’s maiden name. The client requested a field to store the code word and hint, and we provided it. Now, we have been instructed to apply regular password standards to this secret word, like encryption-(how is the collector going to see the code word), min and max length, auto expiration and reuse restrictions.
    All of this is due to the interpation of the SOX act. Is this really needed for this functionality? The code word is really just a standard validation proceedure enacted by the client, that utilize the fields in our software to store the code word.
    This is actualy a training issue. The back up plan for validation is something like the verification of the birth date, should that be encrypted too? If I were to pose that question to our compliance office, the entire application and all associated data would be encrypted and require a password to access the password.



  • That sounds a little crazy to me. How do you enforce normal password attributes like length, and most interestingly - expiration?
    ‘Hello. Please give me your secret password’.
    ‘It’s ‘yellow’’
    ‘Sorry, sir, your passcode has expired, please pick a new one’
    ‘Um, ‘green’’
    ‘Please validate your old passcode first’
    ‘Yellow’.
    ‘Sorry, you used that one already’.
    ‘Ah, hell. I don’t want to pay you anyway. click’.
    Sounds really crazy. I think the key is to get them to not think of this as a logical access password.


Log in to reply