WO2016083778A1 - Location method - Google Patents

Location method Download PDF

Info

Publication number
WO2016083778A1
WO2016083778A1 PCT/GB2015/053364 GB2015053364W WO2016083778A1 WO 2016083778 A1 WO2016083778 A1 WO 2016083778A1 GB 2015053364 W GB2015053364 W GB 2015053364W WO 2016083778 A1 WO2016083778 A1 WO 2016083778A1
Authority
WO
WIPO (PCT)
Prior art keywords
location
transaction
transaction device
location information
user
Prior art date
Application number
PCT/GB2015/053364
Other languages
French (fr)
Inventor
Patrick Carroll
John Petersen
Original Assignee
Validsoft Uk Limited
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Validsoft Uk Limited filed Critical Validsoft Uk Limited
Publication of WO2016083778A1 publication Critical patent/WO2016083778A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/30—Payment architectures, schemes or protocols characterised by the use of specific devices or networks
    • G06Q20/32—Payment architectures, schemes or protocols characterised by the use of specific devices or networks using wireless devices
    • G06Q20/322—Aspects of commerce using mobile devices [M-devices]
    • G06Q20/3224—Transactions dependent on location of M-devices
    • G—PHYSICS
    • G07—CHECKING-DEVICES
    • G07F—COIN-FREED OR LIKE APPARATUS
    • G07F19/00—Complete banking systems; Coded card-freed arrangements adapted for dispensing or receiving monies or the like and posting such transactions to existing accounts, e.g. automatic teller machines
    • G07F19/20—Automatic teller machines [ATMs]
    • G07F19/206—Software aspects at ATMs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q20/00—Payment architectures, schemes or protocols
    • G06Q20/38—Payment protocols; Details thereof
    • G06Q20/40—Authorisation, e.g. identification of payer or payee, verification of customer or shop credentials; Review and approval of payers, e.g. check credit lines or negative lists
    • G06Q20/401—Transaction verification
    • G06Q20/4016—Transaction verification involving fraud or risk level assessment in transaction processing

Definitions

  • the present invention relates to a method and an apparatus for inferring the location of a transaction device, for instance a Point Of Sale (POS) terminal or an Automatic Teller Machine (ATM). Certain embodiments of the present invention are particularly concerned with determining where financial transactions are being performed.
  • POS Point Of Sale
  • ATM Automatic Teller Machine
  • the customer's bank When a customer engages in a transaction with a financial body, for instance using a credit or debit card, the customer's bank must decide whether to authorise the transaction. For example, when a credit card is used to purchase goods from a merchant using a POS terminal, or the customer seeks to withdraw money from an ATM, the issuing bank (the customer's bank which has issued the credit card) must make a rapid decision as to whether to allow the purchase to proceed. Such a decision is typically made by a risk engine controlled by the issuing bank.
  • a risk engine is a risk- based computer system arranged to determine whether to authorise a transaction. A risk engine makes use of predefined rules and relies on a number of data inputs, including the historical behavioural data of both the cardholder and the merchant. If the transaction is not authorised, it can be declined or it can be referred for further consideration.
  • a large number of the transactions about which an issuing bank must make a decision are card-present financial transactions, such as ATM transactions and POS
  • Card-present fraud is a large and increasing problem worldwide, whether the result of lost, stolen or skimmed cards (where a copy of an original card is made which includes all of the necessary information contained within the skimmed card's magnetic strip).
  • "Chip and pin” technology was designed to counter card skimming. However, even in countries such as the UK where this chip and pin is used to authorise transactions, card-present fraud at ATMs and POS terminals is increasing.
  • part of the information used by authorisation engines in the decision-making process for card-present financial transactions comes directly from the details of the transaction itself.
  • This information may include merchant information such as where the transaction physically occurred.
  • Such information is useful because it can be used as part of the authorisation engine's decision making process.
  • the risk engine may be more likely to decline the transaction than for transactions that occur in New York.
  • the transaction information passed to the issuing bank may not include any location information at all.
  • This lack of accurate location data can impede the issuing banks' authorisation engines in their decision making process, especially where they are looking at transactions occurring outside of the cardholder's state of domicile, or where they are attempting to correlate a cardholder's current location with that of the transaction device.
  • An improved determination of the location of a transaction device may, in accordance with certain embodiments of the present invention, make it easier for an issuing bank to determine whether to authorise or decline a card-present financial transaction.
  • Certain embodiments of the present invention allow the creation of a distribution map or table of transaction devices based on location information obtained for customers attempting transactions using those transaction devices. This obviates the need to check the location of a transaction device manually or to rely solely on information provided by the merchant.
  • the distribution map may indicate the confirmed location of a transaction device at a country, state, region, city or other, smaller, level of precision. The benefit to issuing banks of creating this representation is that they can then perform additional and more effective fraud checks than can be performed otherwise.
  • the distribution map may be generated automatically through a self-learning process. Certain embodiments of the present invention are based on the identification of the location of a customer through accessing data held within a Home Location Register (HLR) or other subscriber server of a mobile network to which the customer is a subscriber.
  • HLR Home Location Register
  • a method of inferring a location of a transaction device comprising: receiving an identifier for a transaction device and an identifier for a user associated with a transaction request; determining location information for the user; comparing the determined location information with a database of location information associated with the transaction device; and determining if a location for the transaction device can be inferred based on the result of the comparison.
  • the method may further comprise forming a map or database of inferred locations for a plurality of transaction devices.
  • the transaction device may comprise an automatic teller machine, ATM, or a point of sale, POS, terminal.
  • the identifier for a user may comprise a mobile telephone number for a mobile device associated with the user; and wherein determining location information for the user may comprise sending a request for location information to a subscriber server coupled to a mobile communications network to which the user is a subscriber and receiving location information indicating a geographic location where the mobile device is currently connected to the mobile communications network.
  • the geographic location may comprise a country, a state, city or a region within one or more states or countries.
  • the method may further comprise obtaining a mobile telephone number for a user by access a database of mobile telephone numbers using a separate identifier for a user.
  • Determining location information for the user may comprise: sending a location request to a mobile device associated with the identifier for a user, and receiving location information from the mobile device; or periodically receiving location information from a mobile device associated with the identifier for a user, and determining the most recent location information.
  • Comparing the determined location information with a database of location information associated with the transaction device may comprise identifying if the determined location information matches previously determined location information determined in connection with a previous transaction request. Determining if a location for the transaction device can be inferred based on the result of the comparison may comprise determining if a location for a transaction device exceeds a predetermined confidence level.
  • the confidence level may comprise an indication of the probability that the point of sale terminal is in that location.
  • the method may further comprise updating a confirmation counter associated with that location
  • Determining if a location for the transaction device can be inferred based on the result of the comparison may comprise comparing the confirmation counter to a threshold.
  • an apparatus for inferring a location of a transaction device comprising: a processor arranged to: receive an identifier for a transaction device and an identifier for a user associated with a transaction request; determine location information for the user;
  • Another aspect of the invention provides a computer program comprising instructions arranged, when executed, to implement a method in accordance with any one of the above-described aspects.
  • a further aspect provides machine-readable storage storing such a program.
  • Fig. 1 is a diagram of the major components involved in creating a transaction device distribution map
  • Fig. 2 is a logical representation in the form of a table of the transaction device distribution map
  • Fig. 3 is a flow chart showing the process for building the transaction device distribution map.
  • Embodiments of the present invention will now be described with particular reference to a method for determining the location of a transaction device.
  • the present inventors have recognised that even where a transaction device fails to provide accurate location information it is still usually the case that a transaction device will provide a unique transaction device identifier within a transaction request.
  • the transaction request may be received by or on behalf of the issuing bank from the customer, but including an identifier for the transaction device.
  • the inventors have further recognised that the true location of a transaction device may be inferred from the location of the customer at the time of the transaction, at least for non- fraudulent card-present transactions where the customer associated with the card is at the location of the transaction device. For later card-present fraud associated with that transaction device there may well be a miss-match between the previously inferred location of the transaction device and the location of the customer whose account is being used to commit card-present fraud.
  • a database or map may record the location of transaction devices at the level of country, state, city or more precisely. State or country information may be particularly readily obtainable in accordance with certain embodiments of the present invention owing to the implementation of mobile communication networks. For instance, in the USA when a mobile phone moves between states a network roaming operation typically occurs, which is recorded in a location register held within the home network. In many other parts of the world roaming operations only occur when travelling between countries. However, for performing transaction authorisation an issuing bank risk engine may only require knowledge of whether a transaction is being performed outside of their usual state or country (it not generally being considered to be indicative of card-present fraud for transactions to occur at varying locations within a state or a country).
  • the location determining method may be halted if no mobile phone number is available for the customer.
  • the method may be halted if the location of the transaction device has already been confirmed through previous application of the invention for previous transactions (and possibly previous customers), or if the transaction request contains reliable location data for the transaction device.
  • a determination may be made whether location information for a transaction device and included in a transaction request is reliable based upon prior knowledge that the issuing bank may have for that merchant, that transaction device or that class of merchant or transaction device. For instance, a database may be maintained of retailers who provide reliable location data, for this purpose, though this is outside of the scope of the present invention. Whether the location of the transaction device has previously been confirmed may be determined by checking a database of known point of sale terminal locations, and such a database can be compiled by a computer system operating according to the invention.
  • Identifiers for each transaction device such as serial numbers or the like may be stored, so that the transaction devices can be identified and matched against inferred geographical locations.
  • certain embodiments of the present invention assume that a mobile device associated with a customer is likely to be in the same location as the customer, and that the customer is likely to be in the same location as the transaction device (for a non- fraudulent transaction).
  • the geographical location of the transaction device can be inferred from location data related to the mobile device. It is clear that this assumption is obviously more likely to be true for less precise location information, such as a US state.
  • any level of location information precision can be used, typically depending upon the needs of issuing banks and the accuracy and quantity of the data they can gather.
  • Location information could, for instance, be recorded at the country, state, county, city or district level.
  • the location information precision could be arbitrary, for example a geographical area may be divided up in to nodes which are squares measuring 100 metres to a side.
  • the method may further comprise: assigning a confidence level to at least one location, the confidence level being an indication of the probability that the transaction device is in that location; and identifying the location with the highest confidence level as the true location for the transaction device. If an assumption is made that the transaction device is in the same location as the customer it is clear that this assumption may be false: for instance, the customer may have left their mobile phone in a different location. Hence in accordance with certain embodiments a confidence level is assigned to each location, the confidence level being an indication of the probability that the transaction device is in that node.
  • certain embodiments of the present invention may further comprise receiving at least a second transaction request from the same transaction device, the second transaction request relating to a different customer and performing a similar process of inferring a location for the transaction device. If the inferred locations match, the confidence level of the matched location may be adjusted. This process can be repeated as many times as desired, with as many different customers as are required, provided that the transaction device continues to send useable transaction requests.
  • the method may further comprise identifying the location with the highest confidence level as the location occupied by the transaction device only if the confidence level of that location is also above a predetermined threshold. In this way it can be ensured that a location is not prematurely identified as the location occupied by the transaction device. As the location data from a mobile device may be misleading (for instance if the device is located close to a state border) it may be better to wait until sufficient confirmation is received, and so reduce the risk of identifying a wrong location.
  • the method may further comprise stopping the collection and processing of location data as described above, and so save on time and resources. However, collection and processing location data may continue as described above to ensure an ever greater level of accuracy and also to detect any event where the transaction device is moved between nodes. As a compromise between these two strategies, the method may comprise carrying out spot checks on the transaction device after a location has been identified as the location occupied by the transaction device. These spot checks may be initiated automatically, or manually.
  • the method is arranged to cross reference a mobile device identifier such as a mobile phone number with an item of location data by performing a home location register lookup.
  • a mobile device identifier such as a mobile phone number
  • This solution is especially useful in the United States, where it can be used to identify the state in which a mobile phone was most recently connected.
  • the method is arranged to cross reference a mobile phone number with an item of location data by determining at least one data communication device to which the mobile phone is connected and determining the geographical location of the data communication device.
  • Mobile phones may use a wide variety of data connections. These include long range connections such as those provided by mobile network operators (MNOs), short range radio connections such as Wi-Fi and Bluetooth, and wired connections such as USB ports. All of these routes involve the mobile phone communicating over a known maximum distance with another piece of communications hardware. The location of that communications hardware may be fixed and known, as is the case with mobile phone communications towers, for example. Therefore, depending upon the data connections being used or recently used by the mobile phone, these may be used to calculate an approximate location of the mobile phone.
  • MNOs mobile network operators
  • Wi-Fi and Bluetooth Wireless Fidelity
  • USB ports wireless connections
  • All of these routes involve the mobile phone communicating over a known maximum distance with another piece of communications hardware. The location of that communications hardware may be fixed and known, as is the case with mobile phone communications towers, for example. Therefore, depending upon the data connections being used or recently used by the mobile phone, these may be used to calculate an approximate location of the mobile phone.
  • a mobile phone is connected to a mobile phone communications tower, then it must be within the broadcast radius of that mobile phone communications tower. If that broadcast radius lies within a node, then according to certain embodiments of the invention this may increase the confidence level of that location and decrease the confidence level of any other locations. Similarly, if that broadcast radius lies within a collection of adjoining locations, then a system according to the invention may increase the confidence level of those adjoining locations and decrease the confidence level of any other locations.
  • the mobile phone is connected to more than one piece of communications hardware, for example more than one mobile phone communications tower, then according to certain embodiments of the invention they may be used to calculate the location of the mobile phone more accurately using triangulation, as well as by comparing the broadcast radii of the mobile phone communications towers and assuming that the mobile phone lies within the area where they overlap.
  • a mobile phone number is cross referenced with an item of location data by connecting to the mobile phone and requesting location data from the mobile phone.
  • the mobile phone may comprise a GPS device, or be able to calculate its location based upon data connections to other communications hardware as described above. Therefore the phone may be able to report location data directly according to certain embodiments of the invention.
  • the present invention may be further arranged to use the inferred geographical location of the point of sale terminal in a risk analysis of a transaction request. So for example, when a location has been identified as the node occupied by the point of sale terminal, that information can be used in risk analysis by a card issuing bank. The bank can use the information when deciding whether to allow a transaction request from that point of sale terminal.
  • a computer system can relate to the creation, through a self-learning process, of a US state-based distribution map of point of sale terminals using transaction based Home Location Register (HLR) lookups.
  • HLR Home Location Register
  • Figure 1 shows the major components of a system for creating a transaction device distribution map.
  • An issuing bank risk engine 101 is connected to transaction devices 102 such as POS terminals and ATMs through a network connection such as across the Internet 103.
  • transaction devices 102 such as POS terminals and ATMs
  • the precise nature of the connection of the risk engine 101 to transaction devices 102 may be entirely conventional, and is outside of the scope of the present invention. According to the specific embodiment of the present invention the focus is on transaction devices distributed within the US though it will be understood that the present invention is not limited to application only in the US.
  • the risk engine 101 is arranged to receive transaction requests from the transaction devices 102.
  • the risk engine 101 must decide whether to allow or decline each transaction request, and as part of this it may refer a transaction request to a merchant map processor 104 to determine a location for the transaction device. As discussed above, the risk engine 101 may be arranged to determine whether a transaction request already contains a location for the transaction device, and whether this location is trustworthy. Even if no reliable location for the transaction device 102 is available, the risk engine 101 may not refer a transaction request to the merchant map processor 104. For instance, low value transaction requests may not be referred.
  • the merchant map processor 104 is responsible for determining locations for transaction devices where transaction requests are referred from the risk engine 101. It will be appreciated that in certain embodiments the risk engine 101 and the merchant map processor 104 may be implemented by a single server, or may be collocated.
  • the transaction data which is passed to the merchant map processor 104 as part of a referral may include at a minimum an identifier for a transaction device and identifying information for a mobile device associated with a customer purportedly attempting the transaction.
  • the information identifying a mobile device will be a mobile
  • the merchant map processor 104 in accordance with one embodiment of the present invention is arranged to determine if a confirmed location for the transaction device has already been determined through previous transactions.
  • a confirmed location for a transaction device may be stored in a transaction device location database 105 in the form of a terminal distribution map, as described below in connection with Figure 2. If no confirmed location is available for the transaction device (or in any event, in accordance with certain embodiments) the merchant map processor 104 sends a request to a subscriber server 106 such as a home location register (HLR) within a mobile network associated with the customer.
  • HLR home location register
  • the HLR 106 may return a current state where the mobile device is located. The inference is that assuming the transaction is genuine, that state is also where the transaction device is located.
  • the location obtained for a single transaction device may not be treated as a confirmed location for a transaction device.
  • the location obtained from the HLR 106 may be compared to previous locations obtained through previous transactions using the same transaction device 102.
  • a confidence level may be set at which point a location may be considered to be confirmed for a transaction device 102. For instance, the confidence level may require a predetermined number of matching locations. It may also require that this exceeds alternative locations for the same transaction device 102 (which may be assumed to relate to fraudulent transactions). Other options will be apparent to the skilled person.
  • FIG. 2 shows an example transaction device distribution 201 , on the form of a table.
  • Each entry in the terminal distribution map 201 may include a merchant identifier 202, a transaction device identifier 203, a location 204 and a confidence level.
  • the merchant identifier 202 is a code which uniquely identifies the organisation operating each transaction device.
  • the transaction device identifier 203 is a code which uniquely identifies each transaction device, and is obtained through the transaction request.
  • This data may include things such as the serial numbers of the physical devices.
  • transaction devices can be associated with a unique transaction device identifier 203.
  • the risk engine 101 and the merchant map processor 104 can identify the transaction device making the transaction request.
  • Each entry in the transaction device distribution map 201 also comprises location data 204.
  • the location data 204 comprises a US state.
  • the location of some transaction device may not be known, hence the gap in the location entry for the POS terminal with the identifier 6873579895646.
  • Each entry in the transaction device distribution map 201 comprises a confidence level 205 and a list of all the location results for that transaction device terminal (in the event that multiple locations have previously been retried from a HLR, not shown).
  • the confidence level is shown as a percentage, however it may alternatively be expressed as a confirmation counter which could be incremented each time the same location is obtained from a HLR (described below in connection with Figure 3). For a location to be considered to be confirmed, it may be that the confirmation counter must exceed a predetermined threshold.
  • Figure 3 illustrates a method for creating a transaction device distribution map according to one embodiment of the present invention.
  • the issuing bank's risk engine 101 receives a transaction request for a card-present transaction from a transaction device, for instance a POS terminal.
  • the risk engine 101 determines whether the transaction request includes a reliable location for the merchant. This is may be determined by checking the identity of the merchant within a database. If the merchant is known to provide accurate location data for their POS terminals, and this data is available, then the risk engine will proceed with its analysis of whether to allow or decline the transaction request. If reliable location information is included within the transaction request then the method ends at step 303.
  • the risk engine may determine whether a transaction request can be allowed or declined before checking the reliability of the transaction device location. If the transaction request can be allowed at that stage then the method may go no further. If the transaction request does not include reliable location information for the transaction device then the transaction request, or portions of the transaction request including an identifier for the transaction device is passed to the merchant map processor 104 at step 304. As part of this transfer, the risk engine 101 also checks to see if the customer's mobile phone number is known by the bank.
  • the transaction data passed to the merchant map processor also includes the customer's mobile phone number if this is known.
  • the merchant map processor 104 checks the transaction device's unique identifier 203 in the transaction device distribution map 201 stored in database 105. If the transaction device's location is known and confirmed, meaning that the confidence level of the terminal has risen above a predetermine threshold, then the merchant map processor 104 proceeds to step 306. At step 306 the merchant map processor 104 returns the confirmed location of the transaction device to the risk engine 101 , so that the risk engine 101 can proceed with its analysis of the transaction request. It will be appreciated that even if the merchant map processor 104 holds a confirmed location for the transaction device, in certain embodiments the location of the mobile device associated with the customer for that transaction may still be checked in order to further increase or reduce the confidence in the location for the transaction device.
  • the merchant map processor 104 proceeds to step 307.
  • a check is made whether a mobile phone number for the customer has been received from the risk engine 101. If no mobile phone number has been received then an error code is returned to the risk engine 101 at step 308.
  • the risk engine 101 then proceeds with its analysis of the transaction request without the benefit of location data.
  • the error code may indicate the reason why no confirmed location is available.
  • the merchant map processor 104 and not the risk engine 101 is responsible for obtaining the mobile phone number for the customer and so at step 307 the merchant map processor 104 may perform this retrieval.
  • the merchant map processor 104 performs a home location register (HLR) request using the cardholder's mobile phone number.
  • HLR home location register
  • the merchant map processor 104 is also connected to an HLR database 106, which is maintained by a mobile network operator (MNO).
  • MNO mobile network operator
  • the HLR database includes entries for many mobile phones, each entry comprising at least a unique identifier for each SIM card, and the mobile phone numbers associated with each SIM. As such, the cardholder's mobile phone number can be used to look up data concerning their mobile phone in the HLR database.
  • the HLR database also comprises a record of the cardholder's home location: the geographical area in which their phone is primarily registered.
  • the HLR will also contain a record of their current location.
  • the HLR comprises a typically reliable record of the user's geographical location.
  • the HLR database 106 therefore returns to the merchant map processor 104 an indication of the US State where the mobile phone is connected.
  • the location results for each transaction device derived by the process described above are not absolutely reliable. If the cardholder is not carrying their mobile phone, or if the mobile phone is switched off, then the HLR may return a misleading result. Therefore a confirmation level 205 for each piece of location data 204 in the terminal distribution map 201 must be calculated.
  • the confirmation level 205 is based upon all the location results for a given transaction device which have been derived by the process as outlined above. If all the location results for a transaction device indicate that it is located in California, then it will be listed as located in California, with a high confirmation level. However, if there are only a few confirmation results, or if there are a significant number of contradictory results, then the confirmation level will be low.
  • the confirmation level 205 is typically low. As the entry is updated with each new location result, the confirmation level will tend to rise and fall depending on whether the location agrees or disagrees with the location data 204. If sufficient disagreeing location results are received that a different US state becomes the most likely location for the POS terminal, then the location data 24 is updated accordingly.
  • the returned error code may indicate whether the lack of a match is due to the transaction device not previously having been the subject of a HLR lookup, or due to there being a mismatch to a previously obtained location.
  • a confirmation counter may be incremented. For instance, for a new location for a transaction device, the confidence level may be initialised at 0, or 1 (or any arbitrary value). Each time the same location is returned from a HLR lookup for the same transaction device the confidence level is incremented. A threshold may be set at which point the location is considered confirmed. Figure 2 shows the confidence level expressed as a percentage. This could be calculated on the basis of the current confidence counter as a percentage of the threshold. It will be apparent that in other embodiments the confidence counter could be decremented for each matched location (with a low score indicating a likely genuine location). Further options will be readily apparent to the skilled person.
  • the merchant map processor 104 checks to see if the confirmation counter has risen above the threshold. If it has not, then the merchant map processor 104 returns an error code to the risk engine 101 at step 308.
  • the error code may indicate the number of times that the same location has been returned, or may simply indicate that no confirmed location is available. If however the location is now confirmed, the merchant map processor 104 returns the confirmed location to the risk engine 101 at step 306.
  • the merchant map processor 104 sets the status of the transaction device in the terminal distribution map 201 to "confirmed".
  • the merchant map processor 104 builds up a transaction device distribution map for a plurality of transaction devices.
  • This information is of value to the issuing bank's risk engine for determining whether to allow or decline a transaction request.
  • the issuing bank may decide to decline a transaction request if it is unlikely that a customer is in the same location as the confirmed location for a transaction request.
  • the use that a risk engine may make of the transaction device distribution map is outside of the scope of the present invention.
  • the merchant map processor may be operated by a distinct commercial entity from the issuing bank.
  • the locations confirmed for transaction device may only be on the basis of transaction requests for customers of that issuing bank, or they may be aggregated across the customers of multiple banks.
  • the distribution map may be supplied wholesale to the bank, and perhaps periodically updated, or it may be provided on a subscription basis each time a transaction request is received and the bank wishes to confirm the location of the transaction device.
  • the present invention does not require the storage of any cardholder information in the terminal distribution map.
  • the only customer information that is used is a mobile telephone number for the cardholder, which can be deleted after performing a HLR lookup.
  • the embodiment of the invention described above is set in the USA; however similar embodiments of the invention can be used in any country or countries with a roaming mobile phone system that allows geographical information to be retrieved with an HLR lookup. Further embodiments of the invention may make use other sources to determine the geographical location of the cardholder's mobile phone.
  • the merchant map processor can determine the geographical location of the mobile phone by monitoring in which network segment the mobile phone is located (where
  • the merchant map processor may also determine the geographical location of the mobile phone by monitoring which other data connections the phone is using, for instance local networks such as Wi-Fi. Many mobile devices are able to determine their own location using satellite location systems such as the Global Positioning System (GPS), or by monitoring the mobile network segment to which they are connected. Therefore, in a further embodiment, the merchant map processor may determine the geographical location of the mobile device by communicating directly with the mobile device and requesting that the phone provide location data directly. It is known to seek to prevent card-present fraud through the use of Location Based Services (LBS) using GPS or similar technology at the time of authorising a transaction.
  • LBS Location Based Services
  • similar location information could be obtained from a mobile device associated with the customer, for instance via software installed upon the mobile device at the time a transaction is performed. While LBS based transaction authorisation is problematic due to the slow response times, for the purpose of identifying the location of a
  • an application may be installed upon a mobile device associated with a bank customer.
  • the app may transmit its current location to the merchant map processor (that location being determined according to any available mechanism).
  • the app may provide location information to the merchant map processor each time its location changes (for instance upon crossing a US state border, in the exemplary embodiment set out above).
  • the embodiments of the present invention described above primarily relate to a scenario in which for each transaction device there is a single, fixed location that can be determined. Specifically, in one embodiment it is assumed that once a location for a transaction device has been identified (for instance by HLR lookups) a threshold number of times that location is considered confirmed. Other locations may be considered to relate to fraudulent transactions, or simply ignored. However, this approach may not be appropriate for a situation in which the transaction device may move: as may be the case for micro-merchants such as taxi drivers, market stall holders, travelling sales people and the like. Therefore in certain embodiments of the invention the confirmation counter may not simply be incremented each time there is a match for a single location.
  • the confirmation counter for a previously obtained location may be decremented each time an obtained location fails to match, thereby indicating that reduced future reliance can be placed upon that location.
  • the confirmation counter can be adjusted to place reduced reliance on obtained locations over a certain age, for instance by weighting counts for a location according to the time since that location was obtained. As a simple example, counts for a particular location may be removed once over a threshold age. It will be appreciated that advantageously this would allow a transaction device distribution map to be refreshed to take account of movement of transaction devices. As a further example relating to mobile transaction devices if a location is obtained that is not confirmed, but matches a historical location then this could indicate that the transaction device has been returned to a known location.
  • embodiments of the present invention can be realized in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory, for example RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium, for example a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement embodiments of the present invention.
  • embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same.
  • the words "comprise” and “contain” and variations of them mean “including but not limited to”, and they are not intended to (and do not) exclude other components, integers or steps.
  • the singular encompasses the plural unless the context otherwise requires.

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Strategic Management (AREA)
  • General Business, Economics & Management (AREA)
  • Theoretical Computer Science (AREA)
  • Finance (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Computer Security & Cryptography (AREA)
  • Cash Registers Or Receiving Machines (AREA)
  • Mobile Radio Communication Systems (AREA)

Abstract

A method of inferring a location of a transaction device. The method comprises receiving an identifier for a transaction device and an identifier for a user associated with a transaction request and determining location information for the user. The determined location information is compared with a database of location information associated with the transaction device. A determination is made if a location for the transaction device can be inferred based on the result of the comparison.

Description

LOCATION METHOD
Field of the Invention
The present invention relates to a method and an apparatus for inferring the location of a transaction device, for instance a Point Of Sale (POS) terminal or an Automatic Teller Machine (ATM). Certain embodiments of the present invention are particularly concerned with determining where financial transactions are being performed.
Background to the Invention
When a customer engages in a transaction with a financial body, for instance using a credit or debit card, the customer's bank must decide whether to authorise the transaction. For example, when a credit card is used to purchase goods from a merchant using a POS terminal, or the customer seeks to withdraw money from an ATM, the issuing bank (the customer's bank which has issued the credit card) must make a rapid decision as to whether to allow the purchase to proceed. Such a decision is typically made by a risk engine controlled by the issuing bank. A risk engine is a risk- based computer system arranged to determine whether to authorise a transaction. A risk engine makes use of predefined rules and relies on a number of data inputs, including the historical behavioural data of both the cardholder and the merchant. If the transaction is not authorised, it can be declined or it can be referred for further consideration.
A large number of the transactions about which an issuing bank must make a decision are card-present financial transactions, such as ATM transactions and POS
transactions. In these cases the physical card must be present to complete the transaction. Card-present fraud is a large and increasing problem worldwide, whether the result of lost, stolen or skimmed cards (where a copy of an original card is made which includes all of the necessary information contained within the skimmed card's magnetic strip). "Chip and pin" technology was designed to counter card skimming. However, even in countries such as the UK where this chip and pin is used to authorise transactions, card-present fraud at ATMs and POS terminals is increasing.
In an attempt to limit losses due to card-present fraud, part of the information used by authorisation engines in the decision-making process for card-present financial transactions comes directly from the details of the transaction itself. This information may include merchant information such as where the transaction physically occurred. Such information is useful because it can be used as part of the authorisation engine's decision making process. To take an example based in the USA, if a card which is used in a card-present financial transaction in Texas has a long history of only being used in the state of New York, the risk engine may be more likely to decline the transaction than for transactions that occur in New York.
Whilst generally reliable, information about the physical location of transactions can become an issue when a transaction is performed at a POS terminal of certain major retail organisations. This issue occurs because large organisations do not necessarily comply with the requirements of the issuing banks with regard to providing accurate location information for each POS device. For reasons of convenience it is known that certain major retail organisations operate POS terminals some or all of which indicate that they are in the same physical location (which may be specified at the city, state or country level) when in fact the POS terminals are at widely disparate locations. For instance, all POS terminals may indicate that they are located at the retailer's headquarters.
Additionally, for micro-merchants (typically small organisations or sole traders such as taxi drivers, market stall holders and travelling sales people) the transaction information passed to the issuing bank may not include any location information at all.
This lack of accurate location data can impede the issuing banks' authorisation engines in their decision making process, especially where they are looking at transactions occurring outside of the cardholder's state of domicile, or where they are attempting to correlate a cardholder's current location with that of the transaction device.
Summary of the Invention
It is an aim of certain embodiments of the present invention to provide a method and apparatus for determining a location of a transaction device. An improved determination of the location of a transaction device may, in accordance with certain embodiments of the present invention, make it easier for an issuing bank to determine whether to authorise or decline a card-present financial transaction.
Certain embodiments of the present invention allow the creation of a distribution map or table of transaction devices based on location information obtained for customers attempting transactions using those transaction devices. This obviates the need to check the location of a transaction device manually or to rely solely on information provided by the merchant. The distribution map may indicate the confirmed location of a transaction device at a country, state, region, city or other, smaller, level of precision. The benefit to issuing banks of creating this representation is that they can then perform additional and more effective fraud checks than can be performed otherwise.
Certain embodiments of the present invention may be particularly suited to
implementation in the USA, and allow the determination of which US state a transaction device is within. Coupled with a current state for a customer attempting a transaction (obtained perhaps from a mobile network or notified to an issuing bank in advance) this allows a determination whether the customer is in the same state as the transaction device, and therefore whether it is likely that a transaction is genuine. The distribution map may be generated automatically through a self-learning process. Certain embodiments of the present invention are based on the identification of the location of a customer through accessing data held within a Home Location Register (HLR) or other subscriber server of a mobile network to which the customer is a subscriber.
According to a first aspect of the present invention there is provided a method of inferring a location of a transaction device, the method comprising: receiving an identifier for a transaction device and an identifier for a user associated with a transaction request; determining location information for the user; comparing the determined location information with a database of location information associated with the transaction device; and determining if a location for the transaction device can be inferred based on the result of the comparison.
The method may further comprise forming a map or database of inferred locations for a plurality of transaction devices.
The transaction device may comprise an automatic teller machine, ATM, or a point of sale, POS, terminal.
The identifier for a user may comprise a mobile telephone number for a mobile device associated with the user; and wherein determining location information for the user may comprise sending a request for location information to a subscriber server coupled to a mobile communications network to which the user is a subscriber and receiving location information indicating a geographic location where the mobile device is currently connected to the mobile communications network.
The geographic location may comprise a country, a state, city or a region within one or more states or countries.
The method may further comprise obtaining a mobile telephone number for a user by access a database of mobile telephone numbers using a separate identifier for a user.
Determining location information for the user may comprise: sending a location request to a mobile device associated with the identifier for a user, and receiving location information from the mobile device; or periodically receiving location information from a mobile device associated with the identifier for a user, and determining the most recent location information. Comparing the determined location information with a database of location information associated with the transaction device may comprise identifying if the determined location information matches previously determined location information determined in connection with a previous transaction request. Determining if a location for the transaction device can be inferred based on the result of the comparison may comprise determining if a location for a transaction device exceeds a predetermined confidence level.
The confidence level may comprise an indication of the probability that the point of sale terminal is in that location.
If it is determined that a determined location matches a previously determined location, the method may further comprise updating a confirmation counter associated with that location
Determining if a location for the transaction device can be inferred based on the result of the comparison may comprise comparing the confirmation counter to a threshold.
According to a second aspect of the present invention there is provided an apparatus for inferring a location of a transaction device, the apparatus comprising: a processor arranged to: receive an identifier for a transaction device and an identifier for a user associated with a transaction request; determine location information for the user;
compare the determined location information with a database of location information associated with the transaction device; and determine if a location for the transaction device can be inferred based on the result of the comparison.
Another aspect of the invention provides a computer program comprising instructions arranged, when executed, to implement a method in accordance with any one of the above-described aspects. A further aspect provides machine-readable storage storing such a program.
Advantages of these embodiments are set out hereafter, and further details and features of each of these embodiments are defined in the accompanying dependent claims and elsewhere in the following detailed description. Brief Description of the Drawings
Various aspects of the teachings of the present invention, and arrangements embodying those teachings, will hereafter be described by way of illustrative example with reference to the accompanying drawings, in which:
Fig. 1 is a diagram of the major components involved in creating a transaction device distribution map;
Fig. 2 is a logical representation in the form of a table of the transaction device distribution map; and
Fig. 3 is a flow chart showing the process for building the transaction device distribution map.
Detailed Description of Preferred Embodiments
Embodiments of the present invention will now be described with particular reference to a method for determining the location of a transaction device. The present inventors have recognised that even where a transaction device fails to provide accurate location information it is still usually the case that a transaction device will provide a unique transaction device identifier within a transaction request.
Alternatively, the transaction request may be received by or on behalf of the issuing bank from the customer, but including an identifier for the transaction device. The inventors have further recognised that the true location of a transaction device may be inferred from the location of the customer at the time of the transaction, at least for non- fraudulent card-present transactions where the customer associated with the card is at the location of the transaction device. For later card-present fraud associated with that transaction device there may well be a miss-match between the previously inferred location of the transaction device and the location of the customer whose account is being used to commit card-present fraud.
A database or map may record the location of transaction devices at the level of country, state, city or more precisely. State or country information may be particularly readily obtainable in accordance with certain embodiments of the present invention owing to the implementation of mobile communication networks. For instance, in the USA when a mobile phone moves between states a network roaming operation typically occurs, which is recorded in a location register held within the home network. In many other parts of the world roaming operations only occur when travelling between countries. However, for performing transaction authorisation an issuing bank risk engine may only require knowledge of whether a transaction is being performed outside of their usual state or country (it not generally being considered to be indicative of card-present fraud for transactions to occur at varying locations within a state or a country).
According to certain embodiments of the present invention the location determining method may be halted if no mobile phone number is available for the customer.
Alternatively, the method may be halted if the location of the transaction device has already been confirmed through previous application of the invention for previous transactions (and possibly previous customers), or if the transaction request contains reliable location data for the transaction device. A determination may be made whether location information for a transaction device and included in a transaction request is reliable based upon prior knowledge that the issuing bank may have for that merchant, that transaction device or that class of merchant or transaction device. For instance, a database may be maintained of retailers who provide reliable location data, for this purpose, though this is outside of the scope of the present invention. Whether the location of the transaction device has previously been confirmed may be determined by checking a database of known point of sale terminal locations, and such a database can be compiled by a computer system operating according to the invention.
Identifiers for each transaction device such as serial numbers or the like may be stored, so that the transaction devices can be identified and matched against inferred geographical locations. In effect, certain embodiments of the present invention assume that a mobile device associated with a customer is likely to be in the same location as the customer, and that the customer is likely to be in the same location as the transaction device (for a non- fraudulent transaction). As such, the geographical location of the transaction device can be inferred from location data related to the mobile device. It is clear that this assumption is obviously more likely to be true for less precise location information, such as a US state. However, any level of location information precision can be used, typically depending upon the needs of issuing banks and the accuracy and quantity of the data they can gather. Location information could, for instance, be recorded at the country, state, county, city or district level. The location information precision could be arbitrary, for example a geographical area may be divided up in to nodes which are squares measuring 100 metres to a side.
The method may further comprise: assigning a confidence level to at least one location, the confidence level being an indication of the probability that the transaction device is in that location; and identifying the location with the highest confidence level as the true location for the transaction device. If an assumption is made that the transaction device is in the same location as the customer it is clear that this assumption may be false: for instance, the customer may have left their mobile phone in a different location. Hence in accordance with certain embodiments a confidence level is assigned to each location, the confidence level being an indication of the probability that the transaction device is in that node.
Where confidence levels are used, certain embodiments of the present invention may further comprise receiving at least a second transaction request from the same transaction device, the second transaction request relating to a different customer and performing a similar process of inferring a location for the transaction device. If the inferred locations match, the confidence level of the matched location may be adjusted. This process can be repeated as many times as desired, with as many different customers as are required, provided that the transaction device continues to send useable transaction requests.
Also where confidence levels are used, the method may further comprise identifying the location with the highest confidence level as the location occupied by the transaction device only if the confidence level of that location is also above a predetermined threshold. In this way it can be ensured that a location is not prematurely identified as the location occupied by the transaction device. As the location data from a mobile device may be misleading (for instance if the device is located close to a state border) it may be better to wait until sufficient confirmation is received, and so reduce the risk of identifying a wrong location.
After a location has been identified as the location occupied by the transaction device, the method may further comprise stopping the collection and processing of location data as described above, and so save on time and resources. However, collection and processing location data may continue as described above to ensure an ever greater level of accuracy and also to detect any event where the transaction device is moved between nodes. As a compromise between these two strategies, the method may comprise carrying out spot checks on the transaction device after a location has been identified as the location occupied by the transaction device. These spot checks may be initiated automatically, or manually.
It may be that the method is arranged to cross reference a mobile device identifier such as a mobile phone number with an item of location data by performing a home location register lookup. This solution is especially useful in the United States, where it can be used to identify the state in which a mobile phone was most recently connected.
It may be that the method is arranged to cross reference a mobile phone number with an item of location data by determining at least one data communication device to which the mobile phone is connected and determining the geographical location of the data communication device.
Mobile phones may use a wide variety of data connections. These include long range connections such as those provided by mobile network operators (MNOs), short range radio connections such as Wi-Fi and Bluetooth, and wired connections such as USB ports. All of these routes involve the mobile phone communicating over a known maximum distance with another piece of communications hardware. The location of that communications hardware may be fixed and known, as is the case with mobile phone communications towers, for example. Therefore, depending upon the data connections being used or recently used by the mobile phone, these may be used to calculate an approximate location of the mobile phone.
For example, if a mobile phone is connected to a mobile phone communications tower, then it must be within the broadcast radius of that mobile phone communications tower. If that broadcast radius lies within a node, then according to certain embodiments of the invention this may increase the confidence level of that location and decrease the confidence level of any other locations. Similarly, if that broadcast radius lies within a collection of adjoining locations, then a system according to the invention may increase the confidence level of those adjoining locations and decrease the confidence level of any other locations.
If the mobile phone is connected to more than one piece of communications hardware, for example more than one mobile phone communications tower, then according to certain embodiments of the invention they may be used to calculate the location of the mobile phone more accurately using triangulation, as well as by comparing the broadcast radii of the mobile phone communications towers and assuming that the mobile phone lies within the area where they overlap.
It may be that a mobile phone number is cross referenced with an item of location data by connecting to the mobile phone and requesting location data from the mobile phone.
Mobile phones are frequently provided with various means of calculating their location. For example, the mobile phone may comprise a GPS device, or be able to calculate its location based upon data connections to other communications hardware as described above. Therefore the phone may be able to report location data directly according to certain embodiments of the invention. Typically, the present invention may be further arranged to use the inferred geographical location of the point of sale terminal in a risk analysis of a transaction request. So for example, when a location has been identified as the node occupied by the point of sale terminal, that information can be used in risk analysis by a card issuing bank. The bank can use the information when deciding whether to allow a transaction request from that point of sale terminal.
Hence a computer system according to an embodiment the invention can relate to the creation, through a self-learning process, of a US state-based distribution map of point of sale terminals using transaction based Home Location Register (HLR) lookups.
Referring now to a specific embodiment of the present invention, Figure 1 shows the major components of a system for creating a transaction device distribution map. An issuing bank risk engine 101 is connected to transaction devices 102 such as POS terminals and ATMs through a network connection such as across the Internet 103. The precise nature of the connection of the risk engine 101 to transaction devices 102 may be entirely conventional, and is outside of the scope of the present invention. According to the specific embodiment of the present invention the focus is on transaction devices distributed within the US though it will be understood that the present invention is not limited to application only in the US. The risk engine 101 is arranged to receive transaction requests from the transaction devices 102. As explained above, the risk engine 101 must decide whether to allow or decline each transaction request, and as part of this it may refer a transaction request to a merchant map processor 104 to determine a location for the transaction device. As discussed above, the risk engine 101 may be arranged to determine whether a transaction request already contains a location for the transaction device, and whether this location is trustworthy. Even if no reliable location for the transaction device 102 is available, the risk engine 101 may not refer a transaction request to the merchant map processor 104. For instance, low value transaction requests may not be referred.
The merchant map processor 104 is responsible for determining locations for transaction devices where transaction requests are referred from the risk engine 101. It will be appreciated that in certain embodiments the risk engine 101 and the merchant map processor 104 may be implemented by a single server, or may be collocated.
Alternatively, they may be operated by separate entities and / or may communicate across a network interface and may be remotely located from one another. The transaction data which is passed to the merchant map processor 104 as part of a referral may include at a minimum an identifier for a transaction device and identifying information for a mobile device associated with a customer purportedly attempting the transaction. Typically the information identifying a mobile device will be a mobile
(cellular) telephone number, which may be retrieved by the risk engine 101 or otherwise obtained by or on behalf of the issuing bank.
The merchant map processor 104, in accordance with one embodiment of the present invention is arranged to determine if a confirmed location for the transaction device has already been determined through previous transactions. A confirmed location for a transaction device may be stored in a transaction device location database 105 in the form of a terminal distribution map, as described below in connection with Figure 2. If no confirmed location is available for the transaction device (or in any event, in accordance with certain embodiments) the merchant map processor 104 sends a request to a subscriber server 106 such as a home location register (HLR) within a mobile network associated with the customer. The HLR 106 may return a current state where the mobile device is located. The inference is that assuming the transaction is genuine, that state is also where the transaction device is located.
In accordance with certain embodiments of the present invention, as described below in greater detail in connection with Figure 3, the location obtained for a single transaction device may not be treated as a confirmed location for a transaction device. As one example of why this would be inappropriate, if the transaction is fraudulent the customer's mobile device might very well be in a different state to the transaction device. Consequently, the location obtained from the HLR 106 may be compared to previous locations obtained through previous transactions using the same transaction device 102. A confidence level may be set at which point a location may be considered to be confirmed for a transaction device 102. For instance, the confidence level may require a predetermined number of matching locations. It may also require that this exceeds alternative locations for the same transaction device 102 (which may be assumed to relate to fraudulent transactions). Other options will be apparent to the skilled person.
If the merchant map processor 104 is able to determine or retrieve a confirmed location for the transaction device then this is returned to the risk engine 101. Otherwise an error message may be returned. The error message may provide additional information such as the fact that no location was determined or retrieved from a HLR, or that a location has been retrieved but it has not yet reached the required confidence level to be considered confirmed (the error message may include the unconfirmed location, which may still be of use to the risk engine 101 for determining whether to allow or decline that particular transaction request. Figure 2 shows an example transaction device distribution 201 , on the form of a table. Each entry in the terminal distribution map 201 may include a merchant identifier 202, a transaction device identifier 203, a location 204 and a confidence level. The merchant identifier 202 is a code which uniquely identifies the organisation operating each transaction device. The transaction device identifier 203 is a code which uniquely identifies each transaction device, and is obtained through the transaction request.
Even though some or all of the transaction devices identify themselves as being in the same location, usually the header of transaction requests will include unique
identification data. This data may include things such as the serial numbers of the physical devices. As such, transaction devices can be associated with a unique transaction device identifier 203. The risk engine 101 and the merchant map processor 104 can identify the transaction device making the transaction request.
Each entry in the transaction device distribution map 201 also comprises location data 204. In the example given, the location data 204 comprises a US state. As is explained above, the location of some transaction device may not be known, hence the gap in the location entry for the POS terminal with the identifier 6873579895646.
Each entry in the transaction device distribution map 201 comprises a confidence level 205 and a list of all the location results for that transaction device terminal (in the event that multiple locations have previously been retried from a HLR, not shown). The confidence level is shown as a percentage, however it may alternatively be expressed as a confirmation counter which could be incremented each time the same location is obtained from a HLR (described below in connection with Figure 3). For a location to be considered to be confirmed, it may be that the confirmation counter must exceed a predetermined threshold.
Figure 3 illustrates a method for creating a transaction device distribution map according to one embodiment of the present invention. At step 301 , the issuing bank's risk engine 101 receives a transaction request for a card-present transaction from a transaction device, for instance a POS terminal. At step 302, the risk engine 101 determines whether the transaction request includes a reliable location for the merchant. This is may be determined by checking the identity of the merchant within a database. If the merchant is known to provide accurate location data for their POS terminals, and this data is available, then the risk engine will proceed with its analysis of whether to allow or decline the transaction request. If reliable location information is included within the transaction request then the method ends at step 303. That analysis may be in accordance with entirely conventional processing taking into account factors such as the size of the transaction and the customer's transaction history, and so will not be further described here. It will be appreciated that in accordance with alternative embodiments of the invention the risk engine may determine whether a transaction request can be allowed or declined before checking the reliability of the transaction device location. If the transaction request can be allowed at that stage then the method may go no further. If the transaction request does not include reliable location information for the transaction device then the transaction request, or portions of the transaction request including an identifier for the transaction device is passed to the merchant map processor 104 at step 304. As part of this transfer, the risk engine 101 also checks to see if the customer's mobile phone number is known by the bank. An increasingly large number of cardholders register their number with their bank so that they can be contacted quickly and directly when this is necessary. Hence the bank will typically know the cardholder's mobile phone number. The transaction data passed to the merchant map processor also includes the customer's mobile phone number if this is known.
At step 305, the merchant map processor 104 checks the transaction device's unique identifier 203 in the transaction device distribution map 201 stored in database 105. If the transaction device's location is known and confirmed, meaning that the confidence level of the terminal has risen above a predetermine threshold, then the merchant map processor 104 proceeds to step 306. At step 306 the merchant map processor 104 returns the confirmed location of the transaction device to the risk engine 101 , so that the risk engine 101 can proceed with its analysis of the transaction request. It will be appreciated that even if the merchant map processor 104 holds a confirmed location for the transaction device, in certain embodiments the location of the mobile device associated with the customer for that transaction may still be checked in order to further increase or reduce the confidence in the location for the transaction device.
If on the other hand the determination is that there is no location in the mobile device distribution map 201 for the unique ID of the mobile device, or the status of the entry is not confirmed, the merchant map processor 104 proceeds to step 307. At step 307 a check is made whether a mobile phone number for the customer has been received from the risk engine 101. If no mobile phone number has been received then an error code is returned to the risk engine 101 at step 308. The risk engine 101 then proceeds with its analysis of the transaction request without the benefit of location data. The error code may indicate the reason why no confirmed location is available. In certain other embodiments of the present invention the merchant map processor 104 and not the risk engine 101 is responsible for obtaining the mobile phone number for the customer and so at step 307 the merchant map processor 104 may perform this retrieval. If a mobile phone number is available for the customer then at step 309 the merchant map processor 104 performs a home location register (HLR) request using the cardholder's mobile phone number. Returning to Figure 1 , the merchant map processor 104 is also connected to an HLR database 106, which is maintained by a mobile network operator (MNO). The HLR database includes entries for many mobile phones, each entry comprising at least a unique identifier for each SIM card, and the mobile phone numbers associated with each SIM. As such, the cardholder's mobile phone number can be used to look up data concerning their mobile phone in the HLR database. The HLR database also comprises a record of the cardholder's home location: the geographical area in which their phone is primarily registered. If the cardholder is "roaming", that is travelling outside their home location with their mobile phone turned on then the HLR will also contain a record of their current location. As such the HLR comprises a typically reliable record of the user's geographical location. For the present example in which the invention is implemented in a US for a US customer, the HLR database 106 therefore returns to the merchant map processor 104 an indication of the US State where the mobile phone is connected.
At step 309 a check is made to see whether the returned location matches previously held locations for the transaction device. If that transaction device has not previously been considered by the merchant map processor 104 then an entry is created for the transaction device in the transaction device distribution map 201. The entry comprises the merchant identifier 202 (if available to the merchant map processor 104), the transaction device 203, location data 204 in the form of a US state, and a confirmation level 205. If an entry already exists, then it is updated.
The location results for each transaction device derived by the process described above are not absolutely reliable. If the cardholder is not carrying their mobile phone, or if the mobile phone is switched off, then the HLR may return a misleading result. Therefore a confirmation level 205 for each piece of location data 204 in the terminal distribution map 201 must be calculated.
The confirmation level 205 is based upon all the location results for a given transaction device which have been derived by the process as outlined above. If all the location results for a transaction device indicate that it is located in California, then it will be listed as located in California, with a high confirmation level. However, if there are only a few confirmation results, or if there are a significant number of contradictory results, then the confirmation level will be low.
As such, when an entry on the transaction device distribution map 201 is first created, the confirmation level 205 is typically low. As the entry is updated with each new location result, the confirmation level will tend to rise and fall depending on whether the location agrees or disagrees with the location data 204. If sufficient disagreeing location results are received that a different US state becomes the most likely location for the POS terminal, then the location data 24 is updated accordingly.
At step 310 a check is made whether the location for the transaction device matches a previously obtained location for that transaction device. If no match is present then an error code is returned a step 308 as there can be no certainty that the transaction device location is reliable. Indeed, if this is the first time that the transaction device has been considered then that first transaction request could be fraudulent. Subsequent transaction requests revealing the same location for the transaction device allow an increased confidence that the location is genuine. Similarly if for a transaction device one location is returned repeatedly and then for a new transaction request a different location is returned that does not match then it is likely that the transaction request is fraudulent. The returned error code may indicate whether the lack of a match is due to the transaction device not previously having been the subject of a HLR lookup, or due to there being a mismatch to a previously obtained location.
As one example of the implementation of the confidence level, each time the same location is returned for a transaction device a confirmation counter may be incremented. For instance, for a new location for a transaction device, the confidence level may be initialised at 0, or 1 (or any arbitrary value). Each time the same location is returned from a HLR lookup for the same transaction device the confidence level is incremented. A threshold may be set at which point the location is considered confirmed. Figure 2 shows the confidence level expressed as a percentage. This could be calculated on the basis of the current confidence counter as a percentage of the threshold. It will be apparent that in other embodiments the confidence counter could be decremented for each matched location (with a low score indicating a likely genuine location). Further options will be readily apparent to the skilled person. At step 312 after a confirmation counter has been incremented the merchant map processor 104 checks to see if the confirmation counter has risen above the threshold. If it has not, then the merchant map processor 104 returns an error code to the risk engine 101 at step 308. The error code may indicate the number of times that the same location has been returned, or may simply indicate that no confirmed location is available. If however the location is now confirmed, the merchant map processor 104 returns the confirmed location to the risk engine 101 at step 306. The merchant map processor 104 sets the status of the transaction device in the terminal distribution map 201 to "confirmed".
Over a period of time the merchant map processor 104 builds up a transaction device distribution map for a plurality of transaction devices. This information is of value to the issuing bank's risk engine for determining whether to allow or decline a transaction request. In particular, the issuing bank may decide to decline a transaction request if it is unlikely that a customer is in the same location as the confirmed location for a transaction request. However, the use that a risk engine may make of the transaction device distribution map is outside of the scope of the present invention.
It will be appreciated that the merchant map processor may be operated by a distinct commercial entity from the issuing bank. The locations confirmed for transaction device may only be on the basis of transaction requests for customers of that issuing bank, or they may be aggregated across the customers of multiple banks. The distribution map may be supplied wholesale to the bank, and perhaps periodically updated, or it may be provided on a subscription basis each time a transaction request is received and the bank wishes to confirm the location of the transaction device.
Advantageously, the present invention does not require the storage of any cardholder information in the terminal distribution map. The only customer information that is used is a mobile telephone number for the cardholder, which can be deleted after performing a HLR lookup.
The embodiment of the invention described above is set in the USA; however similar embodiments of the invention can be used in any country or countries with a roaming mobile phone system that allows geographical information to be retrieved with an HLR lookup. Further embodiments of the invention may make use other sources to determine the geographical location of the cardholder's mobile phone. In one embodiment, the merchant map processor can determine the geographical location of the mobile phone by monitoring in which network segment the mobile phone is located (where
geographical locations for the mobile network segments can be obtained from the MNO). The merchant map processor may also determine the geographical location of the mobile phone by monitoring which other data connections the phone is using, for instance local networks such as Wi-Fi. Many mobile devices are able to determine their own location using satellite location systems such as the Global Positioning System (GPS), or by monitoring the mobile network segment to which they are connected. Therefore, in a further embodiment, the merchant map processor may determine the geographical location of the mobile device by communicating directly with the mobile device and requesting that the phone provide location data directly. It is known to seek to prevent card-present fraud through the use of Location Based Services (LBS) using GPS or similar technology at the time of authorising a transaction. In accordance with certain other embodiments of the present invention similar location information could be obtained from a mobile device associated with the customer, for instance via software installed upon the mobile device at the time a transaction is performed. While LBS based transaction authorisation is problematic due to the slow response times, for the purpose of identifying the location of a
transaction device for future transactions in accordance with embodiments of the present invention, the need for rapid location information is less pressing. In particular, in certain embodiments of the invention an application (app) may be installed upon a mobile device associated with a bank customer. Upon receipt of a request from the merchant map processor the app may transmit its current location to the merchant map processor (that location being determined according to any available mechanism). Alternatively, the app may provide location information to the merchant map processor each time its location changes (for instance upon crossing a US state border, in the exemplary embodiment set out above).
The embodiments of the present invention described above primarily relate to a scenario in which for each transaction device there is a single, fixed location that can be determined. Specifically, in one embodiment it is assumed that once a location for a transaction device has been identified (for instance by HLR lookups) a threshold number of times that location is considered confirmed. Other locations may be considered to relate to fraudulent transactions, or simply ignored. However, this approach may not be appropriate for a situation in which the transaction device may move: as may be the case for micro-merchants such as taxi drivers, market stall holders, travelling sales people and the like. Therefore in certain embodiments of the invention the confirmation counter may not simply be incremented each time there is a match for a single location. It may be that in one embodiment it proves possible to have multiple confirmed locations for a single transaction device, the multiple locations representing different locations where the merchant operates. In addition or alternatively the confirmation counter for a previously obtained location may be decremented each time an obtained location fails to match, thereby indicating that reduced future reliance can be placed upon that location. Also, it may be that the confirmation counter can be adjusted to place reduced reliance on obtained locations over a certain age, for instance by weighting counts for a location according to the time since that location was obtained. As a simple example, counts for a particular location may be removed once over a threshold age. It will be appreciated that advantageously this would allow a transaction device distribution map to be refreshed to take account of movement of transaction devices. As a further example relating to mobile transaction devices if a location is obtained that is not confirmed, but matches a historical location then this could indicate that the transaction device has been returned to a known location.
It will be appreciated that embodiments of the present invention can be realized in the form of hardware, software or a combination of hardware and software. Any such software may be stored in the form of volatile or non-volatile storage, for example a storage device like a ROM, whether erasable or rewritable or not, or in the form of memory, for example RAM, memory chips, device or integrated circuits or on an optically or magnetically readable medium, for example a CD, DVD, magnetic disk or magnetic tape or the like. It will be appreciated that the storage devices and storage media are embodiments of machine-readable storage that are suitable for storing a program or programs comprising instructions that, when executed, implement embodiments of the present invention.
Accordingly, embodiments provide a program comprising code for implementing apparatus or a method as claimed in any one of the claims of this specification and a machine-readable storage storing such a program. Still further, such programs may be conveyed electronically via any medium, for example a communication signal carried over a wired or wireless connection and embodiments suitably encompass the same. Throughout the description and claims of this specification, the words "comprise" and "contain" and variations of them mean "including but not limited to", and they are not intended to (and do not) exclude other components, integers or steps. Throughout the description and claims of this specification, the singular encompasses the plural unless the context otherwise requires. In particular, where the indefinite article is used, the specification is to be understood as contemplating plurality as well as singularity, unless the context requires otherwise. Features, integers or characteristics described in conjunction with a particular aspect, embodiment or example of the invention are to be understood to be applicable to any other aspect, embodiment or example described herein unless incompatible therewith. All of the features disclosed in this specification (including any accompanying claims, abstract and drawings), and/or all of the steps of any method or process so disclosed, may be combined in any combination, except combinations where at least some of such features and/or steps are mutually exclusive. The invention is not restricted to the details of any foregoing embodiments. The invention extends to any novel one, or any novel combination, of the features disclosed in this specification (including any accompanying claims, abstract and drawings), or to any novel one, or any novel combination, of the steps of any method or process so disclosed. It will be also be appreciated that, throughout the description and claims of this specification, language in the general form of "X for Y" (where Y is some action, activity or step and X is some means for carrying out that action, activity or step) encompasses means X adapted or arranged specifically, but not exclusively, to do Y.
The reader's attention is directed to all papers and documents which are filed concurrently with or previous to this specification in connection with this application and which are open to public inspection with this specification, and the contents of all such papers and documents are incorporated herein by reference.

Claims

1. A method of inferring a location of a transaction device, the method comprising: receiving an identifier for a transaction device and an identifier for a user associated with a transaction request;
determining location information for the user;
comparing the determined location information with a database of location information associated with the transaction device; and
determining if a location for the transaction device can be inferred based on the result of the comparison.
2. The method of claim 1 , further comprising forming a map or database of inferred locations for a plurality of transaction devices.
3. The method of claim 1 or claim 2, wherein the transaction device comprises an automatic teller machine, ATM, or a point of sale, POS, terminal.
4. The method of any one of the preceding claims, wherein the identifier for a user comprises a mobile telephone number for a mobile device associated with the user; and wherein determining location information for the user comprises sending a request for location information to a subscriber server coupled to a mobile
communications network to which the user is a subscriber and receiving location information indicating a geographic location where the mobile device is currently connected to the mobile communications network.
5. The method of claim 4, wherein the geographic location comprises a country, a state, city or a region within one or more states or countries.
6. The method of claim 4 or claim 5, further comprising obtaining a mobile telephone number for a user by access a database of mobile telephone numbers using a separate identifier for a user.
7. The method of any one of claims 1 to 3, wherein determining location information for the user comprises:
sending a location request to a mobile device associated with the identifier for a user, and receiving location information from the mobile device; or periodically receiving location information from a mobile device associated with the identifier for a user, and determining the most recent location information.
8. The method of any one of the previous claims, wherein comparing the determined location information with a database of location information associated with the transaction device comprises identifying if the determined location information matches previously determined location information determined in connection with a previous transaction request.
9. The method of claim 8, wherein determining if a location for the transaction device can be inferred based on the result of the comparison comprises determining if a location for a transaction device exceeds a predetermined confidence level.
10. The method of claim 8, wherein the confidence level comprises an indication of the probability that the point of sale terminal is in that location.
11. The method of any one of claims 8 to 10, wherein if it is determined that a determined location matches a previously determined location, the method further comprises updating a confirmation counter associated with that location
12. The method of claim 11 , wherein determining if a location for the transaction device can be inferred based on the result of the comparison comprises comparing the confirmation counter to a threshold.
13. An apparatus for inferring a location of a transaction device, the apparatus comprising:
a processor arranged to:
receive an identifier for a transaction device and an identifier for a user associated with a transaction request;
determine location information for the user;
compare the determined location information with a database of location information associated with the transaction device; and
determine if a location for the transaction device can be inferred based on the result of the comparison.
PCT/GB2015/053364 2014-11-24 2015-11-06 Location method WO2016083778A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
GB1420832.6 2014-11-24
GB1420832.6A GB2532512A (en) 2014-11-24 2014-11-24 Location method

Publications (1)

Publication Number Publication Date
WO2016083778A1 true WO2016083778A1 (en) 2016-06-02

Family

ID=52292419

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/GB2015/053364 WO2016083778A1 (en) 2014-11-24 2015-11-06 Location method

Country Status (2)

Country Link
GB (1) GB2532512A (en)
WO (1) WO2016083778A1 (en)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112686663A (en) * 2020-12-25 2021-04-20 中国建设银行股份有限公司 Method and device for determining illegal relocation of POS machine
US20210117975A1 (en) * 2016-03-31 2021-04-22 Square, Inc. Technical fallback infrastructure
US11410177B1 (en) 2017-07-21 2022-08-09 Zonar Systems, Inc. System and method for facilitating investigation of expense card fraud

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10628826B2 (en) 2015-11-24 2020-04-21 Vesta Corporation Training and selection of multiple fraud detection models
US10510078B2 (en) * 2015-11-24 2019-12-17 Vesta Corporation Anomaly detection in groups of transactions

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060237531A1 (en) * 2005-04-26 2006-10-26 Jacob Heffez Method and system for monitoring electronic purchases and cash-withdrawals
US20080162346A1 (en) * 2007-01-03 2008-07-03 Bellsouth Intellectual Property Corporation User terminal location based credit card authorization servers, systems, methods and computer program products
WO2010086608A2 (en) * 2009-01-28 2010-08-05 Validsoft (Uk) Limited Card false-positive prevention

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20060237531A1 (en) * 2005-04-26 2006-10-26 Jacob Heffez Method and system for monitoring electronic purchases and cash-withdrawals
US20080162346A1 (en) * 2007-01-03 2008-07-03 Bellsouth Intellectual Property Corporation User terminal location based credit card authorization servers, systems, methods and computer program products
WO2010086608A2 (en) * 2009-01-28 2010-08-05 Validsoft (Uk) Limited Card false-positive prevention

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20210117975A1 (en) * 2016-03-31 2021-04-22 Square, Inc. Technical fallback infrastructure
US11861623B2 (en) * 2016-03-31 2024-01-02 Block, Inc. Technical fallback infrastructure
US11410177B1 (en) 2017-07-21 2022-08-09 Zonar Systems, Inc. System and method for facilitating investigation of expense card fraud
CN112686663A (en) * 2020-12-25 2021-04-20 中国建设银行股份有限公司 Method and device for determining illegal relocation of POS machine

Also Published As

Publication number Publication date
GB201420832D0 (en) 2015-01-07
GB2532512A (en) 2016-05-25

Similar Documents

Publication Publication Date Title
US10669130B2 (en) System and method for automated analysis comparing a wireless device location with another geographic location
US10776784B2 (en) System and method for automated analysis comparing a wireless device location with another geographic location
US8707319B2 (en) Resource location verification by comparing and updating resource location with a location of a consumer device after a threshold of location mismatches is exceeded
EP2130357B1 (en) Method for tracking credit card fraud
WO2016083778A1 (en) Location method
US10692088B1 (en) Performing actions based on the location of a mobile device during a card swipe
US20130275303A1 (en) Method and system for two stage authentication with geolocation
AU2017204847A1 (en) Method and system of detecting and using geofencing for fraud detection and modeling
US11288674B2 (en) System, method, and computer program product for determining fraud rules
US20140297527A1 (en) System and method for location based validation via mobile device
WO2018035024A1 (en) Systems and methods for enhanced authorization response
US11397945B2 (en) Systems and methods for performing funds freeze and/or funds seizure with respect to prepaid payment cards
US20190188719A1 (en) Computer-Implemented System, Method, and Computer Program Product for Automatically Generating an Account Profile for at Least One User Associated with a Plurality of Account Identifiers
US20180182044A1 (en) Systems and methods for generating a user profile using data associated with cash-based financial transactions
US20170011401A1 (en) Location-based locking and unlocking of payment accounts
US20140279502A1 (en) System and Method of Processing Payment Transactions
US20150278797A1 (en) Location and Proximity Based Authentication
US11488163B2 (en) Dynamic application selection based on contextual data
US20220217144A1 (en) System, Method, and Computer Program Product for Controlling Access to Online Actions
US20220261785A1 (en) Systems and methods for communicating transaction data between mobile devices
KR20150084109A (en) Payment system and method using information of location and time
US11722836B2 (en) Location-based messaging
US10664840B1 (en) Method and system for user address validation

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 15794250

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 15794250

Country of ref document: EP

Kind code of ref document: A1