SECONDARY VALIDATION FOR FRAUD PREVENTION

Banks and other financial institutions struggle to determine when to authorize and when to deny a transaction, such as credit card transactions, for customers. Customers, such as those who travel infrequently or otherwise make purchases at unusual locations, may have transactions denied at such locations. Conversely, stolen credit cards or their numbers, are often utilized in atypical locations for the customer. The provision of a secondary indicator of the customer's location to a bank, such as via an application or a check-in operation on a social media website, allows the bank to determine that the customer is likely at a location associated with a prospective transaction. Confirming a customer's location via a check-in operation, which may require the customer's device and/or social media credentials, provides an extra level of security while minimizing undue denial of legitimate transactions.

FIELD OF THE DISCLOSURE

The present disclosure is generally directed toward authenticating transactions, such as financial transactions.

BACKGROUND

Banks, and other financial institutes, employ many approaches to determining whether a transaction, such as a credit card transaction, is legitimate or potentially fraudulent. Current algorithms for fraud prevention are often too restrictive and conservative. Customers are embarrassed and unhappy when, through no fault of their own, a transaction is denied. It is estimated that half or more of the transactions flagged as fraud and blocked are, in fact, valid purchases.

Banks typically prefer an overly cautious approach. In the event of fraud, it is usually the bank that is the party injured as opposed to the cardholder. In order to minimize exposure to fraudulent transactions, banks track customers' spending trends. However, trends often have exceptions, which may result in denied transactions. Many customers today can call their bank and let them know that they will be traveling. Some banks even have a travel notification on the bank's website so a customer can provide travel details. While these two solutions may result in fewer erroneously denied transactions, they are manual and require the customer to be proactive.

SUMMARY

As a general introduction to the disclosure and in one embodiment, systems and methods are disclosed to enable an authorizing entity to proactively enable transactions in a specific area based on an application's interaction with validation points.

Embodiments disclosed herein provide additional ways for a bank to proactively verify that a customer's activity is legitimate. Banks, or other authorizing entities, may utilize certain embodiments disclosed herein in addition to other authentication means (e.g., determine presence of sufficient funds, transaction within limits, credit card not reported lost/stolen, etc.). In one embodiment, a customer may check into a town, city, destination, resort, etc. that may serve as a validation point to enable transactions in the area.

In additional embodiments, a location may be determined by a check-in and verify feature associated with social media, smartphone, or other location information source. Additionally, a button on the application may allow a “purchase check-in” that can be automatically validated by the bank's server at any time. This may be used with location features for added security, such as by providing a device's location when logging into the application. Embedded telephone location services can also be provided through a car, social media, microchip, etc.

Temporary codes, such as a token, can be provided by the application after location verification for ease of customer use. The temporary codes are set to expire at a previously determined period of time or upon detection of the device at an expiration point. For example, a customer may have checked in at the Miami International Airport and purchases made by the customer in the Miami area may be assumed to be authentic and approved, assuming sufficient funds, staying within daily spending limit, etc. However, if the customer then checks in at a cruise ship dock, the temporary codes provided at the airport may be invalidated as the customer may be boarding a cruise ship. If a credit card is then used in the Miami area, it may be an indication that the card was lost or stolen and, unless subsequently authorized via another validation point, requires other means of validation.

In one embodiment, a method is disclosed, comprising: receiving, by a processor, a request for authorization to perform a transaction between a customer and a party utilizing a transaction terminal, the party having a location; accessing, by the processor, a device location of a device associated with the customer; making an authorization decision, by the processor, comprising, authorizing the transaction upon determining the device location is associated with a validation point and the validation point is associated with the party's location; and replying, by the processor, to the request with indicia of the authorization decision.

In another embodiment, a server is disclosed, comprising: a network interface; a processor to: receive a request for authorization to perform a transaction between a customer and a party utilizing a transaction terminal, the party having a location; access a device location of a device associated with the customer; make an authorization decision, comprising, authorizing the transaction upon determining the device location is associated with a validation point and the validation point is associated with the party's location; and reply to the request with indicia of the authorization decision.

In another embodiment, a means is disclosed to make an authorization decision for a transaction, comprising: means to receive a request for authorization to perform a transaction between a customer and a party at a party location; means to access a device location of a device associated with the customer; means for making an authorization decision, comprising, means to authorize the transaction upon determining the device location is associated with a validation point and the validation point is associated with the party location; and means to reply to the request with indicia of the authorization decision. In a further embodiment, the means provided comprise at least one processor, such as a microprocessor, server, server array, distributed processor (e.g., “cloud”), etc. In another further embodiment, the means comprise a communication network and associated interface to a data network such as to facilitate communication between the a processor and a transaction terminal.

The term “computer-readable medium,” as used herein, refers to any tangible storage that participates in providing instructions to a processor for execution. Such a medium may take many forms, including, but not limited to, non-volatile media, volatile media, and transmission media. Non-volatile media includes, for example, NVRAM, or magnetic or optical disks. Volatile media includes dynamic memory, such as main memory. Common forms of computer-readable media include, for example, a floppy disk, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, magneto-optical medium, a CD-ROM, any other optical medium, punch cards, paper tape, any other physical medium with patterns of holes, a RAM, a PROM, an EPROM, a FLASH-EPROM, a solid-state medium like a memory card, any other memory chip or cartridge, or any other medium from which a computer can read. When the computer-readable media is configured as a database, it is to be understood that the database may be any type of database, such as relational, hierarchical, object-oriented, and/or the like. Accordingly, the disclosure is considered to include a tangible storage medium and prior art-recognized equivalents and successor media, in which the software implementations of the present disclosure are stored.

The term “module,” as used herein, refers to any known or later-developed hardware, software, firmware, artificial intelligence, fuzzy logic, or combination of hardware and software that is capable of performing the functionality associated with that element. Also, while the disclosure is described in terms of exemplary embodiments, it should be appreciated that other aspects of the disclosure can be separately claimed.

DETAILED DESCRIPTION

Any reference in the description comprising an element number, without a subelement identifier when a subelement identifier exists in the figures, when used in the plural, is intended to reference any two or more elements with a like element number. When such a reference is made in the singular form, it is intended to reference one of the elements with the like element number without limitation to a specific one of the elements. Any explicit usage herein to the contrary or providing further qualification or identification shall take precedence.

The exemplary systems and methods of this disclosure will also be described in relation to analysis software, modules, and associated analysis hardware. However, to avoid unnecessarily obscuring the present disclosure, the following description omits well-known structures, components, and devices that may be shown in block diagram form, and are well known or are otherwise summarized.

For purposes of explanation, numerous details are set forth in order to provide a thorough understanding of the present disclosure. It should be appreciated, however, that the present disclosure may be practiced in a variety of ways beyond the specific details set forth herein.

FIG. 1depicts environment100in accordance with embodiments of the present disclosure. In one embodiment, customer102with device104is at validation point106. Validation point106generally comprises a limited area (e.g., a point on earth), which can reliably indicate the presence of the customer, or, more particularly, device104controlled by customer102, within a sufficiently finite area. Device104may then communicate with server116via network114to provide server116with a means of maintaining a record of the location of device104and therefore of customer102.

In another embodiment, customer102wishes to perform a transaction with a party at a party's location. The party may utilize transaction device108to, at least in part, obtain authorization from authorization agency112(e.g., bank, credit card service bureau, etc.) before the transaction is approved and funds are transferred or authorized to be transferred from customer102to the party. The party may be automated with the transaction device (e.g., kiosk) or comprise a human intermediary (e.g., business agent, salesperson, business owner, etc.) utilizing transaction device108(e.g., point-of-sale terminal, card reader, etc.). Transaction device108communicates with authorization agency112via network1(110), which may be a private network, public network (e.g., Internet), or a combination thereof. Network1(110) may be different from, or partially or entirely the same as, network2(114). Network1(110) may differ in terms of security (e.g., encryption, VPN, etc.). Transaction device108may further comprise a general purpose communication device, such as a telephone, used by a human agent to call authorization agency112to obtain a verbal and/or textual authorization over network1(110) (e.g., cellular telephone network, VoIP, PSTN, etc.).

In another embodiment, authorization agency112may be integrated with, integrated by, or co-integrated with server116. In yet another embodiment, server116is distinct from authorization agency112. For example, server116may comprise a social media website accessed by customer102utilizing device104, such as to perform the check-in function. The check-in function may identify the location coinciding with verification point106. Customer102may utilize device104, such as by the execution of an application associated with server116, such as a social media server, to identify a particular venue during a check-in process. For example, customer102may check in at an airport, restaurant, hotel, entertainment venue, address, etc. as a validation point106associated with a particular area.

In another embodiment, authorization agency112receives a request from transaction device108to approve a transaction associated with a monetary token (e.g., check, credit card, etc.) associated with the customer102. Authorization agency112may perform a number of individual determinations in order to approve or disapprove the transaction. For example, customer102, may be attempting to utilize the monetary token beyond an approved amount, the monetary token may have been previously reported as missing or stolen, or other determination as to whether customer102should be permitted to conduct the transaction requested by transaction device108. Transaction device108may have a location and be a proxy for the location of a party for which customer102wishes to perform the transaction.

Authorization agency112may further determine whether to approve or disapprove the transaction based upon such a location of transaction device108and the likelihood of customer102being in an area likely to comprise transaction device108, as opposed to an unauthorized party in possession of the monetary token in an attempt to impersonate customer102for the purpose of conducting the transaction with the party utilizing transaction device108.

Authorization agency112may access server116to obtain a location provided by device104. Upon determining device104is at validation point106, or has been at validation point106within a previously determined period of time, authorization agency112may determine with reasonable certainty that customer102is proximate to transaction terminal108and thereby conclude that the transaction is legitimate. Upon determining the transaction is legitimate, and all other authorization determinations have been determined in favor of the transaction, authorization agency112, may inform transaction terminal108, such as by utilizing network1(110), that the transaction has been approved. Conversely, authorization agency112may access server116and access a record maintaining a location of device104. If the record does not indicate the presence of device104at validation point106, or does not indicate the presence of device104at validation point106within a previously determined period of time, authorization agent112may notify transaction terminal108to decline the transaction or withhold approval until alternative verification of the party purporting to be customer102is obtained (e.g., authorization agency112may initiate a voice or text communication with device104to perform a challenge-response authentication).

The location of the party and the transaction may be assumed to be a location for transaction terminal108. In one embodiment, validation point106is associated with the location of transaction terminal108and the presence of device104at validation point106may be required to access transaction terminal108. For example, validation point106may be a concert venue. Access to transaction terminal108, such as to purchase merchandise associated with a performer at the concert venue, may require that device104be at validation point106. Authorization agency112may obtain a record previously provided by device104indicating a location of the concert venue. Or, in response to a transaction utilizing transaction terminal108, authorization agency112may prompt user102using device104, such as via server116or other connection, to indicate their location (e.g., “Please check into ‘The Concert Hall’ to authorize your current transaction.”). While not all legitimate transactions may be associated with an associated validation point106, the absence of such a location may indicate a suspicious transaction and be declined by authorization agent112or require alternative authentication. For example, customer102may take the train to another city. Validation point106, such as at the airport in the same city, may not be visited by customer102and device104. However, the presence of device104at validation point106may be a significantly strong indicator that a transaction with a party utilizing transaction terminal108is authentic and avoid unnecessarily denying a transaction.

A transaction between a party utilizing transaction terminal108and customer102may be co-located with validation point106. In another embodiment, transaction terminal108and customer102may be separated by a significant distance. For example, customer102with device104may check in at Denver International Airport. A transaction utilizing terminal108may be requested and approved, even though the location of transaction terminal108may be over two-hundred miles away in Montrose, nearby Black Canyon of the Gunnison being known for camping and other remote recreational activities. Additional authentication can be provided upon accessing a credit card purchase for a rental car to be picked up at the airport. Conversely, customer102and device104may not have provided any check-in reasonably associated with the area causing the transaction utilizing transaction terminal108in Montrose to be declined, or at least require alternative authentication.

In another embodiment, check-in or presence at validation point106may be time-dependent. For example, device104may be at validation point106associated with access to beach resorts. Accordingly, device104, having a location of validation point106such as at Honolulu International Airport, may be reasonably proximate to transaction terminal108located in Maui. As a benefit, customer102need not have device104during the transaction utilizing transaction terminal108for the transaction to be approved by authorization agency112.

FIG. 2depicts environment200in accordance with embodiments of the present disclosure. In one embodiment, the location of device104may be determined by customer102utilizing device104to check into validation point106. In another embodiment, the location of device104may be determined via a location-aware application on device104receiving a location, such as by another device (e.g., a Bluetooth connection to a location-aware vehicle206or other device), GPS via satellite204, connectivity to radio-frequency transmitter (e.g., cellular tower202, WiFi transmitter installed at a known location, etc.).

In one embodiment, customer102utilizing device104connects via Bluetooth to rental car206having a known pick-up origin associated with validation point106. Device104then signals server116, via network2(114) to create and/or update a record maintained by server116indicating check-in at validation point106. As a result, authentication agency112may communicate with transaction terminal108via network1(110) to authorize a transaction when transaction terminal108is associated with validation point106. Similarly, location may be provided to server116as determined by satellite204and or radio-frequency (or other electromagnetic frequency) transmitter202.

In another embodiment, device104may be provided with a temporary code to be provided to transaction terminal108. The temporary code may more readily provide the identification of device104having been at validation point106. For example, an application on device104may instruct customer102to enter code “3456” if asked for a secondary verification by transaction terminal108. Authentication agency112may prompt or receive the temporary code as a component of an authentication process utilizing transaction device108. The transaction code may be short and human-readable, such as to facilitate customer102remembering the temporary code and not requiring customer102to write down the temporary code or carry device104. In another embodiment, the temporary code may be lengthy and/or encrypted to make the presence of device104essential to the authentication process for a transaction utilizing transaction terminal108. The temporary code may expire upon the passage of a predetermined duration of time and/or upon device104being associated with a location different from validation point106and/or a return visit. For example, a check-in at a foreign airport may be associated with a record maintained by server116and/or a temporary code and further associated with transaction terminal108. A subsequent visit to the same airport, or a different port of entry/departure (e.g., dock, train station, etc.) may indicate customer102is no longer to be associated with any transaction terminal associated with validation point106, thereby expiring the temporary code and/or causing the record maintained by server116to be updated to reflect a potential departure.

In another embodiment, authentication agency112may determine a type of transaction requested by transaction terminal108and associated with customer102and approve or deny (or require alternative authentication) accordingly. For example, it may not be unusual for customer102to make a significant purchase at a grocery store once a month. However, the grocery store may be close to the residence of customer102, as people making large grocery purchases rarely do so far from their home. In a foreign country, however, customer102may have to check in or otherwise be present at a particular validation point106, as a large grocery purchase may be uncommon and, therefore, such a transaction request by transaction terminal108may be denied. A routine purchase of groceries in a foreign location may be an indication that customer102is no longer in possession of their credit card and another individual is impersonating customer102. Accordingly, the transaction may be declined. Alternatively, a purchase at transaction terminal108associated with a local fine-dining restaurant may be approved, even if the amount is similar or more than the amount associated with the denied grocery store purchase, as such a transaction may be more typical for a tourist known to be visiting another country.

FIG. 3depicts interaction300in accordance with embodiments of the present disclosure. In one embodiment, device104associated with customer102provides indicia of location302to server116. In one embodiment, indicia of location302is provided via a social media application communicating with server116when embodied as a social media server. In another embodiment, indicia of location302is provided to server116when embodied as a server co-owned and/or operated by authorization authority112. Indicia of location302may be a check-in to provide the location, which may be a city, country, venue, hotel, restaurant, or other named location and/or a physical location on earth (e.g., GPS position). Indicia of location302may be an indicia of relative proximity to a radio or other electromagnetic source (e.g., WiFi, AM-FM, cellular, Bluetooth device, etc.) when device104is receiving signals therefrom.

Record update304creates and/or updates at least one record maintained by server116. The record may be maintained internally to server116or accessible to server116(e.g., external database, distributed storage, etc.). Customer102may initiate transaction306with a party utilizing transaction terminal108. Transaction terminal108may request authorization308from authentication agency112. As can be appreciated, communications with authentication agency112may be machine-based, such as when authentication agency112is accessed via a data network for electronic communication with transaction terminal108. In another embodiment, transaction terminal108may be a human communication device (e.g., telephone, chat, etc.) to an automated or human resource of authentication agency112to provide text-based or verbal-based transaction approval and disapproval for a particular transaction.

Authentication agency112may perform non-location validation310, such as to determine if the transaction initiated in step306is performed with a valid credit card, check, or other monetary proxy, or if the transaction value is within preset spending limits, etc. Location is suspect312determines that the location for transaction terminal108in combination with customer102is suspect. Next, authentication agency112may interface with server116to access a location, such as a check-in location associated with a validation point106as maintained in the record created/updated in step304. If customer102is likely proximate, as determined by location record entry provided in step314, the transaction may be authorized in step316allowing transaction terminal108to complete the transaction318.

If not present, server116may request location412from device104. Request412may be a retrieval or a prompt from either customer102to provide a location or location indicia or from a location aware application running on device412. For example, request412may prompt customer102to check in using device104(or other device) at a certain location, such as a location associated with validation point106. Upon receiving indicia of location414, server116may provide customer location416to authentication agency112. In response, authentication agency112may authorize transaction418allowing for transaction terminal108to complete the transaction420.

FIG. 5depicts process500in accordance with embodiments of the present disclosure. In one embodiment, process500is performed to update a location associated with a customer, such as customer102. Customer102utilizes a device, such as device104, to check in502. Check-in502's location is stored in step504, such as in a database or other data repository maintained by a server, such as server116.

FIG. 6depicts process600in accordance with embodiments of the present disclosure. In one embodiment, process600is initiated at step602wherein a request for transaction authorization is received, such as from transaction terminal108. Step604accesses a device location, such as maintained by server116following a check-in operation (See,FIG. 5step502) and stored (see,FIG. 5, step504). Device location604may be an identity of a validation point, such as validation point106, having a previously determined location. In another embodiment, step604is performed before step602. Step606determines if the location of the transaction, such as by a known location of transaction terminal108, is associated with the validation point, such as validation point106. If step606is determined in the affirmative, process600may continue to step608, if implemented, or if not, to step608. Optional step608determines if the transaction is in accord with the particular customer at the particular location of the transaction request. If step608is determined in the affirmative, process600may continue to step612. If step608is determined in the negative, process600may continue to step610. If step610is performed, the transaction may be declined or alternatively an alternative authentication may be required, which, if successful, may cause the transaction to be approved. If step612is performed, the transaction may be authorized, such as by sending a signal to transaction terminal108or a voice indication provided to a party associated with transaction terminal108.

Aspects of the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.) or an embodiment combining software and hardware aspects that may all generally be referred to herein as a “circuit,” “module” or “system.” Any combination of one or more computer-readable medium(s) may be utilized. The computer-readable medium may be a computer-readable signal medium or a computer-readable storage medium.