Security and fraud are a large concern for most consumer-oriented organizations. Any time personally sensitive information is collected from a consumer, care must be taken to protect that data from exploitation. What might be considered personally sensitive information? Usually, this includes account numbers, identification numbers, member numbers, credit card numbers, expiration dates, CVVs, checking routing numbers, checking account numbers, social security numbers, PIN, etc. Anything that is used to identify or authenticate a consumer may be considered sensitive.

Within the context of speech technology, there is one main security issue. Naive callers may blurt out sensitive account information over the phone within earshot of ne'er-do-wells, so the possibility of overheard information needs to be considered. For greatest flexibility, plan to prompt callers to “say or enter” sensitive information so they may select the option with which they're most comfortable after the initial prompt. You may even consider only prompting the caller to enter account-sensitive information if fraud is of particular concern.

There are two additional security issues that aren't relegated solely to speech technology, but need to be considered with the design of any self-service tool. The first issue is the logging of recognized or entered information. IVR and multi-modal applications, if well designed, log events that occur during the course of the interaction with the consumer. However, any time the caller enters sensitive information, the application must be architected to log only as much data as required to be effective. For example, ANI is a useful piece of information to use in event logging, because phone number can be used in lieu of account number to track repeated callers. However, in some organizations, phone numbers are considered sensitive and should not logged. At the very least, if the decision is made not to log specific digits that are entered as strings, it's a good idea to log the number of digits entered for tuning and analysis purposes later on.

The second self-service design issue relates to handling of failures during the identification and authentication process. Assume the following scenario: an app takes an account number, pulls up a customer profile, asks for the PIN (or whatever is being used for authentication), compares the provided PIN to the profile, discovers it's wrong, then comes back and tells the caller, “That PIN doesn't match your profile.” What we've just told the user and potential fraudster: “hey buddy, you entered a valid account number that exists in our system, AND of the possible 9,999 PINs associated with that account number, you have eliminated one incorrect one.” To protect account holders from this situation, the better approach is to collect the account number, then the PIN, compare them with the appropriate customer profile. If they don't match, just say something simple such as, “That account number and PIN don't match one another. Let's start over.”