When a security is bought or sold for a client by a broker-dealer, the broker-dealer must send a confirmation of the trade to its client. A conventional confirmation is a paper record of the trade mailed to the client using the postal service containing a brief summary of the transaction, including, but not limited to, a description of the security traded, the type of transaction, the quantity bought or sold, the date of execution, and the unit price. For each transaction the broker-dealer executes, a separate confirmation is mailed, although multiple confirmations may share the same envelope, and a transaction requested by a client may be executed in several transactions by the broker-dealer.
Confirming a trade can benefit the client by informing the client that a trade was properly performed. If the trade was made pursuant to an order to sell or buy at a particular price, referred to as a “limit order”, the client may not know that a trade has occurred pursuant to the order until the confirmation is received. Confirming a trade can also benefit the client by allowing the client to correct errors that may have been made in execution. Thus, confirmations are mailed quickly, such as within three days after the trade was executed. Confirming a trade can also provide a recognized source of tax information: for example, the confirmation can describe the basis amount in a stock held by a client.
There are several problems with mailing confirmations. First, the process is expensive. Mailing confirmations involves not only generation of documents, but also folding, inserting into envelopes, and affixing postage. Because millions of securities transactions occur per day, millions of confirmations must be sent; multiplied accordingly, the labor and postage costs of mailing each individual confirmation accrue to a high total cost for the broker-dealer.
Second, until the client receives the confirmation of the trade, he may not know the exact price at which or date at which the trade was executed. With a few days added for mail delays, nearly a week can pass before the client is notified of the trade. Some clients find this length unacceptably long, particularly if it can affect their actions with respect to other trades.
If the transaction occurs over the Internet, the client might be able to access information about the trade through a web-site, but this method of retrieval would require connecting to the site, logging on, navigating the site, and requesting the appropriate information, a cumbersome and time-consuming process. If the trade is executed pursuant to a limit order, the client would have to repeatedly check the status on the website, a cumbersome process. Because each such transaction costs the broker-dealer money and uses resources, such as those of a server, such repeated checking drives up the costs and occupies resources that may be put to another use or not needed if the client did not check the status repeatedly. Furthermore, the information located via the web could not be used as evidence of the cost basis in the security for income tax purposes.
One possible solution to the problem would be to e-mail confirmations of trades. Such an approach would reduce the costs and delays associated with mailing the confirmation, provide a nearly instantaneous confirmation and prevent repeated checking via a website. However, if the e-mail message is not received, the intended recipient of the e-mail may not be able to respond to and correct a mistake or an unauthorized trade that could have been promptly corrected.
There are several reasons an e-mail message may not be received by the intended recipient. For example, some e-mail messages are received by an intermediate server before they are forwarded on to the recipient's server. The intermediate server may be a backup server that operates to accept messages for the recipient's server when the recipient's server is not available. If the intermediate server mishandles the message, it may not be forwarded to the intended recipient.
Another reason an e-mail message may not be received by the intended recipient is due to misdirection of the e-mail message, for example because of a mistake or the activities of a hacker. When a sending system sends an e-mail message, one or more servers, each known as a name server, is used to translate the mail domain (the portion of the e-mail address to the right of the ‘@’ sign) into an Internet Protocol (IP) address of a master name server for the recipient. The master name server is then used to identify the IP addresses of one or more specific mail servers that can receive the e-mail message and provide the message to the recipient.
If any of these servers has incorrect information, the e-mail message may not be delivered to its intended recipient. This could arise because of a mistake in setting up these servers or because a hacker had replaced the IP address of his or her own server in place of the IP address of the intended recipient's domain name server or had replaced the IP address of the specific mail server to which the message is sent with the IP address of the hacker's mail server. The message would then be sent to the hacker's mail server in place of the mail server that will forward the message to the recipient. If the hacker was the party who caused an unauthorized trade to be executed, the misdirection of the e-mail confirmation could allow the hacker extra time before his or her actions were detected.
What is needed is a system and method that can prevent an e-mail message from being sent to an intermediate server and can prevent an e-mail message from being delivered to an incorrect recipient server.
USPTO Backgrounds
USPTO Backgrounds