The background description provided herein is for the purpose of generally presenting the context of the disclosure. Work of the presently named inventors, to the extent it is described in this background section, as well as aspects of the description that may not otherwise qualify as prior art at the time of filing, are neither expressly nor impliedly admitted as prior art against the present disclosure.
Financial transaction instruments such as payment cards used by individuals may be sponsored by another entity, such as a corporation or even a parent. The sponsor may wish to limit the use of card to transactions that are consistent with the sponsors policies and/or values.
Features and advantages described in this summary and the following detailed description are not all-inclusive. Many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims hereof. Additionally, other embodiments may omit one or more (or all) of the features and advantages described in this summary.
In some embodiments, transaction authorizations received for an individual payment card are compared to a list of businesses that fall outside the guidelines established for use of that payment card. When the request is associated with such a business, a flag is set and the transaction authorization may be denied.
The figures depict a preferred embodiment for purposes of illustration only. One skilled in the art may readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein.
A sponsor of a financial instrument, as used here, may be a corporate, government, or an individual who provides a payment instrument to a person for use on behalf of the sponsor. In some cases, a corporation may provide a credit card to an employee who acts on behalf of the of corporation. The employee may be a buyer who purchases goods and services for the corporation, may be a salesperson who entertains customers and potential customers, or may be an executive who travels frequently on behalf of the company. In another case, a parent may give a credit card to a child who is away at school for use in paying school and living expenses.
In most cases, the sponsor has a set of values and standards (either corporate or personal) that define some kind of acceptable use. In many cases, the standards involve acceptable use of the sponsor's funds and the difficulty of explaining use of the payment instrument at establishments that are at odds with the sponsor's values. When inappropriate charges do occur, it may often be difficult to untangle the financial and public relations impacts. For example, not only may a company be obligated to pay the offending charge but it must then decide what action to take against the employee.
While many obvious cases of such “off-limits” establishments may involve adult entertainment, gambling, or legalized drugs, others may also apply. A company that sells vegan products may not want their card used at a steak house. A parent whose child lives on a walking campus may not want the student paying for gas. High-end audio or computer gaming equipment may not fall within the bounds of expected employee purchases.
In an embodiment, a merchant 104 may initiate a financial transaction by accepting a payment instrument 102 to complete a purchase. The payment instrument 102 may be any of several methods of conveying payment details including, but not limited to, a physical card, a tokenized value presented via a cell phone, or a barcode (not depicted). The merchant 104 may forward a payment bundle including its own merchant identifiers, the payment amounts, payment instrument details, and transaction type, among others. An acquirer 106 (also called merchant acquirer or payment gateway) may accept the transaction details and route a request for approval of the transaction to a processor 108. In an embodiment, the processor 108 may be a network such as Visa®. If the payment instrument 104 is in tokenized form, the token may be processed to recover a personal account number (PAN). Otherwise, a PAN may be extracted from the transaction request.
At this point, a flagging function 110 may examine the transaction request, and more particularly, the PAN. The flagging function 110 may determine if the PAN of the transaction request belongs to a set of PANs for which restrictions have been placed. For example, a database of such PANs 111 may be consulted using the PAN as an index. If the PAN has no restrictions and/or is not present in the database 111, the transaction may be processed conventionally.
If, however, the PAN is present in the database 111 and has restrictions, the flagging function 110 may further compare merchant/location information from the transaction to a dataset (or database) of locations 112. The dataset of locations 112 may indicate whether the merchant 104 is to be blocked from transactions for the current PAN. There are numerous ways in which the comparison may be made, as will be discussed more below. However, in general, a merchant/location reference associated with the PAN may indicate which locations to search for in the dataset of locations 112. A match between the merchant 104 and an entry in the dataset of locations 112 may indicate that a sponsor of the payment instruments 102 has requested that transactions with that merchant 104 are to be rejected. In nominal transaction processing flows, the transaction processor 108 does not approve or reject transactions, with that responsibility falling on the bank 114 or issuer of the payment instrument 102. In order to retain the nominal flow of processing, the transaction request may simply be supplemented with a flag. A flagged transaction processing function 116 at the bank 114 may read the flag indicating that the transaction merchant/location is not authorized for that PAN. The bank 114 may then simply reject the transaction request using either a new or an existing failure code. That is, the acquirer 106 and ultimately the merchant 104 will be notified that the payment instrument has been denied and a holder of the payment instrument will either need to reconsider the transaction or use a another, likely personal, payment instrument.
There are also several conditions which may affect the ability to uniquely identify a merchant or location. For example, some merchants may share identifying information or share an address. In other cases, a payment processor may act as a clearinghouse for transactions so the actual provider of goods or services may be not be obvious from the details of the transaction request. The response to an inability to fully identify a merchant/location may be handled in several ways, according to a preference of the transaction processor 108, an issuer 114, or the sponsor of the payment instrument 102. In one case, an inability to completely identify the merchant 104 may result in no flag being set and the transaction being allowed to continue for normal processing. In another case, such an inability to identify the merchant 104 with specificity may result in the flag being set and the transaction being denied.
In order to provide the data necessary for flagging transactions, three sets of data may be generated. The first may be a list of payment instruments for which blocking is to be applied. A second may be a list of merchants or categories that a payment instrument sponsor wishes the block. The third may be a dataset of merchants and/or their locations that meet the criteria for blocking specified by the sponsor.
In order to populate the first list, illustrated in
The second dataset, the list of merchants to be blocked, may be populated in one embodiment by the card sponsor 120, also via the user interface (UI) 122. In some cases, the UI 122 may simply be a browser that connects to a host via an application program interface (API) 118. Turning briefly to
The third set of data required for flagging transactions may be a list of merchant locations 124. Such a database 124 may exist as part of a registration function of the transaction processor 108 simply as a means of establishing a business relationship to support processing payment cards. Such a list 124 may be independently developed and maintained and may include assigned or self-defined references to business types such as a merchant category code (MCC).
Further to making the comparison of data from the transaction request to merchants/locations to be blocked,
The client ID column may indicate a card sponsor for which transactions are to be blocked. That is, a merchant in a row where the client ID appears are to be denied. While the contents of the illustrated table are simplified, the actual contents of a such a table may be complex. For example, many more client identifiers may be included in the Client ID column. However, in some cases, a unique table 130 may be generated for each client/card sponsor wishing to block transactions. In that case, no Client ID column would be needed since the table itself would be dedicated to an individual card sponsor.
A technical effect of the described system and method is the use of an application program interface (API) 118 and user interface 122 for presenting selectable choices to a card sponsor 120 for selective transaction blocking. The UI 122 may be hosted by an issuing bank 114 associated with the card sponsor 120 or a transaction processor 108 hosting a dataset of locations 112. The user interface 122 implements a technological solution to a longstanding problem of abuse of financial instruments dedicated to a particular purpose.
These techniques benefit card sponsors, card issuers, and ultimately card users. By blocking transactions before they occur, disputed transactions are avoided, along with human relations (HR) actions for employees involved in such transactions and possible chargebacks involving issuing banks 114, acquirers 106 and the merchants 104 themselves.
The figures depict preferred embodiments for purposes of illustration only. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles described herein
Upon reading this disclosure, those of skill in the art will appreciate still additional alternative structural and functional designs for the systems and methods described herein through the disclosed principles herein. Thus, while particular embodiments and applications have been illustrated and described, it is to be understood that the disclosed embodiments are not limited to the precise construction and components disclosed herein. Various modifications, changes and variations, which will be apparent to those skilled in the art, may be made in the arrangement, operation and details of the systems and methods disclosed herein without departing from the spirit and scope defined in any appended claims.