Technical Field and Background
[0001] The present disclosure relates to a method and system for processing data. In particular, it provides methods and systems for assessing potential locations for automated teller machines from transaction data.
[0002] Automated teller machines (ATMs) allow holders of payment cards to carry out transactions and banking operations without the requirement to enter a bank. One of the most common uses for an ATM is to withdraw cash. ATMs are typically operated and maintained by issuers of payment cards such as banking institutions or by service companies.
[0003] Currently most of the issuers or service companies providing new ATM installation services use point of interest data or location parameters such as estimated traffic per day, location popularity, weekend or week day traffic, the distance to the nearest ATM etc. to identify new locations to install ATMs.
Summary
[0004] The described embodiments of the present invention include a method and system for assessing potential locations for ATM machines based on transaction data. Specifically, ATM transaction data obtained from a plurality of individual machines each of a particular issuing financial institution is processed with respect to a candidate location representing a possible location for a new ATM. Statistical analysis is applied to the transaction data to determine one or more significant transaction metrics (such as, for example, the amount total withdrawn from the ATM, or the number of withdrawal transactions conducted at the ATM, over a particular time interval) that are processed to generate a location score for the candidate location indicating the relative suitability of that location for the deployment of a new ATM.
[0005] In the described embodiments, the transaction metrics are obtained from the transaction data via the application of Generalized Linear Model (GLM) analysis, and/or other regression or statistical analysis techniques, to a set of variables of the transaction data that may potentially be significant indicators of ATM behavior. The transactions represented by the transaction data can be of a specific type, such as for example including only data
3
corresponding to ATMs from a particular issuing financial institution, or data obtained during a particular time period. Survival analysis is applied to determine the location score via the generation of survival distribution functions (SDFs) which model the survival of relevantly located existing ATMs for each transaction metric. Clustering and/or pattern recognition techniques are applied to the transaction data prior to the generation of the SDFs in order to categorize the behavior of the ATMs according to the available transaction data.
[0006] Under the assumption that ATMs with similar behavior share similar survival properties (i.e. where the “survival” of an ATM ceases when that ATM rejects a transaction request due to insufficient funds being available to complete the transaction), SDF data is processed in conjunction with representative transaction metric data in order to determine corresponding survival (and hence failure) probabilities of a new ATM that is expected to belong to a particular behavior category. Failure probabilities of the new ATM in respect of the transaction metrics, as produced by the generated SDFs of that behavioral category, are combined to generate the location score for the candidate location. Generation of location scores for a plurality of candidate locations allows the system and methods to recommend a particular one of the locations for the deployment of the new ATM (such as, for example, by selecting the location with the highest failure score, indicating a respective lowest probability of survival of ATMs in the vicinity of the location).
[0007] According to a first aspect of the present invention, there is provided a computer implemented method of assessing a potential location for an automated teller machine (ATM), the method comprising:
receiving, at an ATM location assessment server, transaction data corresponding to transactions in a geographic area including the potential location;
receiving, at the ATM location assessment server, ATM data representing, at least, an indication of a number of automated teller machines in the geographic area including the potential location;
identifying, in a transaction identification module of the ATM location assessment server, one or more transactions represented by the transaction data;
processing, in a transaction metric calculation module of the ATM location assessment server, the identified transactions to generate transaction metric data representing one or more transaction metrics, said transaction metrics being significant to the survival of one or more ATMs within the geographic area, where the survival of an ATM ceases when said
4
ATM rejects a transaction request due to insufficient funds being available at the ATM to complete the requested transaction;
generating, in a survival distribution generation module of the ATM location assessment server, one or more survival distribution functions which model the survival of ATMs within the geographic area including the potential location with respect to the one or more transaction metrics; and
calculating, in a score calculation module of the ATM location assessment server, a location score for the potential location using the one or more survival distribution functions, the location score representing the suitability of the potential location for deploying a new ATM.
[0008] In a second aspect, there is provided an apparatus for assessing a potential location for an automated teller machine, the apparatus comprising:
a computer processor and a data storage device, the data storage device having a transaction identification module; a transaction metric calculation module; a survival distribution generation module; and a score calculation module comprising non-transitory instructions operative by the processor to:
receiving transaction data corresponding to transactions in a geographic area including the potential location;
receiving ATM data representing, at least, an indication of a number of automated teller machines in the geographic area including the potential location;
identifying one or more transactions represented by the transaction data;
processing the identified transactions to generate transaction metric data representing one or more transaction metrics, said transaction metrics being significant to the survival of one or more ATMs within the geographic area, where the survival of an ATM ceases when said ATM rejects a transaction request due to insufficient funds being available at the ATM to complete the requested transaction;
generating one or more survival distribution functions which model the survival of ATMs within the geographic area including the potential location with respect to the one or more transaction metrics; and
calculating a location score for the potential location using the one or more survival distribution functions, the location score representing the suitability of the potential location for deploying a new ATM.
Brief Description of the Drawings
5
[0009] Embodiments of the invention will now be described for the sake of non-limiting example only, with reference to the following drawings in which:
Fig. 1 is a block diagram of a data processing system according to an embodiment of the present invention;
Fig. 2 is a block diagram of a data processing system that generates payment network data used in methods according to embodiments of the present invention
Fig. 3 is a block diagram illustrating a technical architecture of the apparatus according to an embodiment of the present invention;
Fig. 4 is a flowchart illustrating a method of assessing a potential location for an automated teller machine according to an embodiment of the present invention;
Fig. 5 is a flowchart showing the process of calculating transaction metric data according to the location assessment method of the present invention;
Fig. 6 is a flowchart showing the generation of survival distribution functions according to the location assessment method of the present invention;
Fig. 7 is an illustration of a survival distribution function for a transaction metric according to an embodiment of the present invention; and
Fig. 8 is a block diagram illustrating an assessment module of an assessment server according to an embodiment of the present invention.
Detailed Description
[0010] The present invention provides a method to calculate scores for a number of different candidate ATM locations and, based on the resulting scores, determine a preferred location for a new ATM. Based on estimates of the transaction metric values for a pre-determined period of time, for example three months, the new ATM is ascertained to belong to clusters 𝑘𝑙1,𝑘𝑙2 and 𝑘𝑙3respectively within these locations. Therefore, since failure scores Fl1(kl1),Fl2(kl2) and Fl3(kl3) represent the probability of failure of ATMs of similar behavior to the new ATM (i.e. with corresponding cluster membership) in each candidate location, the method can be configured to choose the location with the highest failure score as the preferred destination for the new ATM. This results in the location of ATMs in a location where similarly behaving ATMs are most likely to fail, correspondingly providing
6
customers with an additional ATM to use in the event of a failure, and therefore reducing revenue loss of the ATM vendor (i.e. the issuer).
[0011] Figure 1 is a block diagram showing a data processing system according to an embodiment of the present invention. The data processing system 100 comprises an automated teller machine (ATM) location assessment server 200. The ATM location assessment server 200 is coupled to a payment network database 110, and a database 120 storing ATM data.
[0012] The payment network database 110, and the ATM database 120 may be resident on different servers or server clusters. The servers may be either within a single data warehouse or distributed over a plurality of data warehouses. The data processed by the ATM location assessment server 200 may be retrieved from the servers, and cleaned and stored in a data warehouse prior to the analyses being conducted. Alternatively, the ATM location assessment server 200 may receive the data from servers which may be operated by the different providers.
[0013] The payment network database 110 comprises transaction data 115. The transaction data 115 comprises indications of transactions, which indicates information including the time and date of transactions; transaction amount; the card number of a payment card used for the transaction, or another number which uniquely identifies the card, without being the primary account number (PAN) itself; and the merchant or the ATM at which the transaction was carried out.
[0014] The ATM database 120 stores ATM data 116 which can include ATM locations and transactions captured at those ATMs. As mentioned above, the ATM database 120 may be separate from the payment network database 110. Whenever a new ATM is set up, ATM data 116 relating to the new ATM is provided to the ATM data base 120, including for example its physical location and/or network address and/or an identifier such as a serial number.
[0015] Figure 2 shows an example of a transaction processing system 300 which generates the payment network data 110. As shown in Figure 2, the ATM location assessment server 200 receives transaction data from a payment network 170, such as the payment network operated by MasterCard.
[0016] The payment network 170 acts as an intermediary during a merchant transaction being made by a cardholder 152 using a payment card 160 at a merchant terminal 162 of a
7
merchant 154 or an ATM transaction made by the cardholder 152 using an ATM 163. In particular, the cardholder 152 may present the payment card 160 to merchant terminal 162 of merchant 164 as payment for goods or services. The merchant terminal 162 may be a point of sale (POS) device such as a magnetic strip reader, chip reader or contactless payment terminal, or a website having online e-commerce capabilities, for example. A merchant 154 may operate one or a plurality of merchant terminals 162. The merchant terminal 162 communicates with an acquirer computer system 168 of a bank or other institution with which the merchant 154 has an established account, in order to request authorisation for the amount of the transaction (sometimes referred to as ticket size) from the acquirer system 168. In some embodiments, if the merchant 154 does not have an account with the acquirer 168, the merchant terminal 162 can be configured to communicate with a third-party payment processor 166 which is authorised by acquirer 168 to perform transaction processing on its behalf, and which does have an account with the acquirer entity. The ATM 163 communicates with an ATM acquirer computer system 168 of a bank or financial institution which manages the ATM 163. The processing of the transaction by the ATM acquirer computer system 169 is carried out in an analogous manner to the processing carried out by the acquirer 168 for transactions at the merchant 154.
[0017] The acquirer system 168 or the ATM acquirer system 169 routes the transaction authorisation request from the merchant terminal 162 or ATM 163 to computer systems of the payment network 170. The transaction authorisation request is then routed by payment network 170 to computer systems of the appropriate issuer institution (e.g., issuer 174) based on information contained in the transaction authorisation request. The issuer institution 174 is authorised by payment network 170 to issued payment card 160 on behalf of customers 152 to perform transactions over the payment network 170. Issuer 174 also provides funding of the transaction to the payment network 170 for transactions that are approved.
[0018] The computer systems of the issuer 174 analyse the authorisation request to determine the account number submitted by the payment card 160, and based on the account number, determine whether the account is in good standing and whether the transaction amount is covered by the cardholder’s account balance or available credit. Based on this, the transaction can be approved or declined, and an authorisation response message transmitted from issuer 174 to the payment network 170, which then routes the authorisation response message to the acquirer system 168. The acquirer system 168, in turn, sends the
8
authorisation response message to merchant terminal 162 or the ATM. If the authorisation response message indicates that the transaction is approved, then the account of the merchant 154 (or of the payment processor 166 if appropriate) is credited by the amount of the transaction following subsequent clearing and settlement processes, or for the case of an ATM transaction, the cardholder is allowed to make a cash withdrawal and the cardholder’s account is debited accordingly.
[0019] During each authorisation request as described in the previous paragraphs, the payment network 170 stores transaction information in a payment network database 110 accessible via a database cluster 172. The database cluster 172 may comprise one or more physical servers. In some embodiments, the payment network database 110 may be distributed over multiple devices which are in communication with one another over a communications network such as a local-area or wide-area network. In some embodiments, the payment network database 110 may be in communication with a data warehousing system 180 comprising a data warehouse database 182 which may store copies of the transaction data, and/or cleaned and/or aggregated data which are transformed versions of the transaction data.
[0020] Transaction records (or aggregated data derived therefrom) may be directly accessible for the purposes of performing analyses, for example by the ATM location assessment server 200, from payment network database 110. Alternatively, or in addition, the transaction records (or aggregated data derived therefrom) may be accessed (for example, by the ATM location assessment server 200) from the data warehouse database 182. Accessing the transaction records from the data warehouse database 182, instead of the transactions database 110, has the advantage that the load on the payment network database 110 is reduced.
[0021] The transaction records may comprise a plurality of fields, including acquirer identifier/card accepter identifier (the combination of which uniquely defines the merchant); merchant category code (also known as card acceptor business code), that is, an indication of the type of business the merchant is involved in (for example, a gas station); cardholder base currency (i.e., U.S. Dollars, Euros, Yen, etc.); the transaction environment or method being used to conduct the transaction; the transaction type; card identifier (e.g., card number); time and date; location (full address and/or GPS data); transaction amount (also referred to herein as ticket size); terminal identifier (e.g., merchant terminal identifier or
9
ATM identifier); and response code (also referred to herein as authorization code). Other fields may be present in each transaction record.
[0022] Each terminal identifier may be associated with a merchant 154, or an ATM 163. Typically, a particular merchant 154 will have a plurality of merchant terminal identifiers, corresponding to merchant terminals 162, associated with it.
[0023] Figure 3 is a block diagram showing a technical architecture of the ATM location assessment server 200 for performing an exemplary method 400 which is described below with reference to Figure 4. Typically, the method 400 is implemented by a computer having a data-processing unit. The block diagram as shown Figure 3 illustrates a technical architecture 200 of a computer which is suitable for implementing one or more embodiments herein.
[0024] The technical architecture 200 includes a processor 222 (which may be referred to as a central processor unit or CPU) that is in communication with memory devices including secondary storage 224 (such as disk drives), read only memory (ROM) 226, and random access memory (RAM) 228. The processor 222 may be implemented as one or more CPU chips. The technical architecture 220 may further comprise input/output (I/O) devices 230, and network connectivity devices 232.
[0025] The secondary storage 224 is typically comprised of one or more disk drives or tape drives and is used for non-volatile storage of data and as an over-flow data storage device if RAM 228 is not large enough to hold all working data. Secondary storage 224 may be used to store programs which are loaded into RAM 228 when such programs are selected for execution. In this embodiment, the secondary storage 224 has a transaction identification module 224a, a transaction metric calculation module 224b, a survival distribution generation module 224c, and a score calculation module 224d comprising non-transitory instructions operative by the processor 222 to perform various operations of the method of the present disclosure. As depicted in Figure 3, the modules 224a-224d are distinct modules which perform respective functions implemented by the ATM location assessment server 200. It will be appreciated that the boundaries between these modules are exemplary only, and that alternative embodiments may merge modules or impose an alternative decomposition of functionality of modules. For example, the modules discussed herein may be decomposed into submodules to be executed as multiple computer processes, and, optionally, on multiple computers. Moreover, alternative embodiments may combine multiple instances of a particular module or submodule. It will also be appreciated that,
10
while a software implementation of the modules 224a-224d is described herein, these may alternatively be implemented as one or more hardware modules (such as field-programmable gate array(s) or application-specific integrated circuit(s)) comprising circuitry which implements equivalent functionality to that implemented in software. The ROM 226 is used to store instructions and perhaps data which are read during program execution. The secondary storage 224, the RAM 228, and/or the ROM 226 may be referred to in some contexts as computer readable storage media and/or non-transitory computer readable media.
[0026] I/O devices 230 may include printers, video monitors, liquid crystal displays (LCDs), plasma displays, touch screen displays, keyboards, keypads, switches, dials, mice, track balls, voice recognizers, card readers, paper tape readers, or other well-known input devices.
[0027] The network connectivity devices 232 may take the form of modems, modem banks, Ethernet cards, universal serial bus (USB) interface cards, serial interfaces, token ring cards, fiber distributed data interface (FDDI) cards, wireless local area network (WLAN) cards, radio transceiver cards that promote radio communications using protocols such as code division multiple access (CDMA), global system for mobile communications (GSM), long-term evolution (LTE), worldwide interoperability for microwave access (WiMAX), near field communications (NFC), radio frequency identity (RFID), and/or other air interface protocol radio transceiver cards, and other known network devices. These network connectivity devices 232 may enable the processor 222 to communicate with the Internet or one or more intranets. With such a network connection, it is contemplated that the processor 222 might receive information from the network, or might output information to the network in the course of performing the above-described method operations. Such information, which is often represented as a sequence of instructions to be executed using processor 222, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave.
[0028] The processor 222 executes instructions, codes, computer programs, scripts which it accesses from hard disk, floppy disk, optical disk (these various disk based systems may all be considered secondary storage 224), flash drive, ROM 226, RAM 228, or the network connectivity devices 232. While only one processor 222 is shown, multiple processors may be present. Thus, while instructions may be discussed as executed by a processor, the instructions may be executed simultaneously, serially, or otherwise executed by one or multiple processors.
11
[0029] Although the technical architecture 200 is described with reference to a computer, it should be appreciated that the technical architecture may be formed by two or more computers in communication with each other that collaborate to perform a task. For example, but not by way of limitation, an application may be partitioned in such a way as to permit concurrent and/or parallel processing of the instructions of the application. Alternatively, the data processed by the application may be partitioned in such a way as to permit concurrent and/or parallel processing of different portions of a data set by the two or more computers. In an embodiment, virtualization software may be employed by the technical architecture 200 to provide the functionality of a number of servers that is not directly bound to the number of computers in the technical architecture 200. In an embodiment, the functionality disclosed above may be provided by executing the application and/or applications in a cloud computing environment. Cloud computing may comprise providing computing services via a network connection using dynamically scalable computing resources. A cloud computing environment may be established by an enterprise and/or may be hired on an as-needed basis from a third party provider.
[0030] It is understood that by programming and/or loading executable instructions onto the technical architecture 200, at least one of the CPU 222, the RAM 228, and the ROM 226 are changed, transforming the technical architecture 200 in part into a specific purpose machine or apparatus having the novel functionality taught by the present disclosure. It is fundamental to the electrical engineering and software engineering arts that functionality that can be implemented by loading executable software into a computer can be converted to a hardware implementation by well-known design rules.
[0031] Various operations of the exemplary method 400 will now be described with reference to Figure 4 in respect of assessing a potential location for an automated teller machine (ATM). It should be noted that enumeration of operations is for purposes of clarity and that the operations need not be performed in the order implied by the enumeration.
[0032] The method is carried out to assess a potential location for an ATM. The potential location may be country, a region of a country, a city or a specific area of a city.
[0033] In step 402, the ATM location assessment server 200 receives transaction data from the payment network database 110. The transaction data may be received in response to a query or request from the ATM location assessment server 200. The received transaction data relates to transactions in a geographic area including the potential location.
12
[0034] The transaction data relating to the geographic area may be identified using fields of the transaction data, for example geographical information specifying the latitude and longitude co-ordinates of a terminal or ATM where a transaction took place, a merchant postcode, or postcode associated with an ATM at which a transaction took place, city name information associated with either a merchant or ATM, or other information which allows the transaction data relating to a specific geographic region to be identified.
[0035] In step 404, ATM location assessment server 200 receives ATM data including an indication of the existing ATMs located in the geographic area.
[0036] The ATM data received in step 404 indicates information in relation to the ATMs in the geographic area of interest, including the number of ATMs in the geographic area of interest, and data relating to one or more properties of the ATMs.
[0037] In step 406, the transaction identification module 224a of the ATM location assessment server 200 identifies transactions of one or more transaction types that are to be used in the following analysis. The types of transaction identified by the transaction identification module 224a can be based on the geophysical origin of the transaction, such as: domestic ATM transactions; cross border ATM transactions; domestic non-ATM transactions; and cross border non-ATM transactions. Transaction types can be used to identify particular transactions as ATM transactions or non-ATM transactions using merchant identifiers or terminal identifiers.
[0038] In the described embodiments, the identification of a transaction as a cross-border transaction or a domestic transaction is performed from an indication of a card issuing country in the transaction data. If the card issuing country is the same as the country of the geographic location then the transaction is determined to be a domestic transaction. If the card issuing country is different from the country of the geographic location the transaction is determined to be a cross border transaction. Information on the country of card origination, card type, transaction amount etc. may be used in the analysis.
[0039] The transaction identification module 224a can be configured to identify ATM transactions which occurred during an analysis period. The analysis period may be selected as a period greater than one year, for example two years. A period greater than one year can be selected in order to even out possible seasonal variations may occur for periods of less than one year. Further a period of two years may also be beneficial to even out other economic variations.
13
[0040] Transactions can be limited to those conducted using payment cards 160 issued by, or conducted at ATM machines of, a particular issuer 174. For example, the system can define an “Issuer A” transaction type such that transactions belonging to this type are those transactions that are conducted at an ATM machine of Issuer A. This allows the system to assess the location of a new ATM based on data representing transactions performed by customers of Issuer A.
[0041] In step 408, the metric calculation module 224b of the ATM location assessment server 200 calculates a set of M transaction metrics for each type of transaction. Figure 5 illustrates the process of calculating the transaction metrics for a particular transaction type. In step 502, the metric calculation module 224b retrieves global transaction metric data representing a plurality of variables in relation to transactions performed at particular ATMs within the geographical location. In the described embodiments, and with respect to a particular ATM, the variables can include (by non-limiting example):
a. the amount of cash withdrawn per day;
b. the amount of cash withdrawn per day from all ATMs within a predetermined area (relative to the ATM);
c. the number of withdrawal transactions per day;
d. the number of withdrawal transactions per day from all ATMs within a predetermined area (relative to the ATM);
e. the ratio of a/b;
f. the ratio of c/d;
g. the ratio of a/c
h. the ration of b/d;
i. the ratio of g/h
j. the amount of cash withdrawn per day from a particular payment card;
k. the amount of cash withdrawn per day from a particular card and from all ATMs within a predetermined area (relative to the ATM);
14
l. the number of withdrawal transactions per day from a particular payment card; and
m. the number of withdrawal transactions per day from a particular payment card from all ATMs within a predetermined area (relative to the ATM).
[0042] Global variable data is obtained from the transaction data and/or ATM data for each ATM within the geographical location. The metric calculation module 224b determines the transaction metrics as a subset of significant variables of the global variable set. In the described embodiments, in step 504 generalized linear model (GLM) analysis is performed to identify the transaction metrics for a given transaction type that are significant to whether an ATM will reject a transaction request due to insufficient funds being available to complete the transaction (i.e. to the survival of the ATM). For example, where M=2 the transaction metrics may include: the total number of withdrawal transactions per day (variable c); and the amount of cash withdrawn per day (variable a).
[0043] In step 506, the metric calculation module 224b processes the transaction data to determine transaction metric values (i.e. the values of the significant global variables, as described above) for each ATM within the geographical location. The metric calculation module 224b partitions the set of ATMs according to the transaction metric values in order to determine one or more behavioural states, where the transaction behaviour of each ATM within the location can be represented in terms of the transaction metric values of an appropriately chosen state.
[0044] In the described embodiments, K-means clustering is applied (in step 508) to the transaction metric data to produce a predetermined number K of ATM clusters. ATMs within the same cluster are assumed to behave similarly (according to the transaction metrics), and share common Survival Distribution Functions (SDFs) that model the survival of ATMs with respect to the transaction metrics, and which are determined by methods described below.
[0045] In step 510, the metric calculation module 224b generates transaction metric state data for each determined cluster, or state, such as in the form of an array of transaction metric values representing the cluster in the metric space. The skilled addressee will appreciate that, in other embodiments, alternative clustering and/or pattern classification techniques may be used by the metric calculation module 224b, including unsupervised classification
15
which can partition the ATMs without requiring the number of clusters, or states, to be predetermined.
[0046] In step 410, the survival distribution generation module 224c of ATM location assessment server 200 calculates survival distribution functions (SDFs) for each ATM cluster using the transaction metric data (as determined in step 408) of ATMs belonging to the cluster. In the described embodiments, an ATM is considered to survive while the ATM has the necessary funds remaining to dispense transactions. Survival ceases when the ATM is forced to reject a transaction request due to an insufficiency of funds to complete the transaction (referred to herein as the “failure” of the ATM).
[0047] Figure 6 illustrates the process of calculating the SDFs of each ATM cluster. In step 602, the survival distribution generation module 224c processes the transaction data to obtain data values for the transaction metrics of each ATM within the cluster. In step 604, the transaction data values of each ATM that do not correspond to failure are censored to generate survival data for the ATM.
[0048] In step 606, a univariate analysis of the transaction data is performed with respect to a particular transaction metric (e.g. amount of cash withdrawn per day). Univariate analysis of the data can include performing statistical analyses, such as for example the application of statistical tests including the Student’s Test, the Sign Test, and/or the Signed Rank (Wilcoxon) Test, on the transaction metric values of the cluster. The transaction metric values can be processed based on the univariate analysis, such as, for example, to remove outliers that may otherwise negatively affect the accuracy of the generated SDF.
[0049] In step 608, the survival distribution generation module 224c generates a Survival Distribution Function (SDF) for the cluster using the processed and censored transaction metric data. In the described embodiments, Kaplan-Meier analysis is applied to produce the SDFs, an example 700 of which is illustrated for the ‘amount of cash withdrawn per day’ transaction metric in Figure 7. The survival distribution generation module 224c repeats the SDF generation process for each transaction metric (i.e. in step 610) such that a set of M SDFs is produced for each ATM cluster, each SDF corresponding to a particular transaction metric.
[0050] In step 412, the score calculation module 224d of the ATM location assessment server 200 generates failure probabilities for each ATM cluster using the transaction metric SDFs generated in step 410. Failure probabilities are calculated using transaction metric state data
16
(e.g. the expectation of the transaction metric for the cluster when the clusters are derived via the K-means technique). In step 414, the score calculation module 224d calculates a score for the location by combining the failure probabilities calculated in step 412.
[0051] In the described embodiments, the location score is in the form of a ‘failure score’ that is calculated by multiplying each of the failure probabilities of the transaction metrics by a corresponding weight.. The weights may be used to emphasise particular metrics in relation to others when determining the preferred location for a new ATM. For example, for a transaction metric set of cardinality M where X1… XM are the probabilities of failure of an ATM belonging to cluster k with respect to the metrics, and W1…WM are the corresponding weights applied to these metrics, the failure score Fl(k) for an ATM belonging to cluster k at the location l is calculated as:
Fl(k)= (𝑊1∗𝑋1)+(𝑊2∗𝑋2)+⋯+(𝑊𝑀∗𝑋𝑀)(𝑊1+𝑊2+⋯+𝑊𝑀)
[0052] In other embodiments the location score may be calculated by applying analysis or classification techniques to the failure probability values directly. The calculation of transaction types, determination of transaction metric data, generation of SDFs for each metric and determined ATM cluster, and the subsequent generation of location scores (as based on failure probabilities) can be conducted in offline processing stages. The corresponding data produced by the aforementioned steps can be stored in the modules 224a-d and retrieved at runtime (i.e. when the system is required to make an assessment of a particular location for a new ATM) for the purpose of improving computational efficiency.
[0053] In some embodiments, separate scores may be calculated for different types of transaction such as ATM transactions and non-ATM transactions. Scores for the different transaction types may be combined to produce location scores for each candidate location in addition, or as an alternative, to the methods described herein above.
[0054] Particular embodiments of the invention can be used to calculate scores for a number of different candidate ATM locations and, based on the resulting scores, determine a preferred location for a new ATM. For example, consider three candidate locations 𝑙1,𝑙2,and 𝑙3 for the placement of a new ATM. Based on estimates of the transaction metric values, the new ATM is determined to belong to clusters 𝑘𝑙1,𝑘𝑙2 and 𝑘𝑙3respectively within these locations. Therefore, since failure scores Fl1(kl1),Fl2(kl2) and Fl3(kl3) represent the probability of
17
failure of ATMs of similar behavior to the new ATM (i.e. with corresponding cluster membership) in each candidate location, the system can be configured to choose the location with the highest failure score as the preferred destination for the new ATM. This results in the placement of the ATM in the location where similarly behaving ATMs are most likely to fail, thus providing customers with an additional ATM to use in the event of a failure, and therefore reducing revenue loss of the ATM vendor (i.e. the issuer).
[0055] Referring to Figure 8, there is shown an assessment module 800 of the assessment server 200. The assessment module 800 comprises a transaction identification sub-module 802, a transaction metric calculation sub-module 804, a survival distribution generation sub-module 806, and a score calculation sub-module 808. The sub-modules 802, 804, 806, 808 are distinct sub-modules which perform respective functions implemented by the assessment server 200. It will be appreciated that the boundaries between these sub-modules are exemplary only, and that alternative embodiments may merge sub-modules or impose an alternative decomposition of functionality of sub-modules. Moreover, alternative embodiments may combine multiple instances of a particular sub-module. It will also be appreciated that, while a software implementation of the sub-modules 802, 804, 806, 808 is contemplated, these may alternatively be implemented as one or more hardware modules (such as field-programmable gate array(s) or application-specific integrated circuit(s)) comprising circuitry which implements equivalent functionality to that implemented in software.
[0056] It should be appreciated that the transaction identification sub-module 802 identifies transactions of one or more transaction types that are to be used in the aforementioned analysis. The types of transaction identified by the transaction identification sub-module 802 can be based on the geophysical origin of the transaction, such as: domestic ATM transactions; cross border ATM transactions; domestic non-ATM transactions; and cross border non-ATM transactions. Transaction types can be used to identify particular transactions as ATM transactions or non-ATM transactions using merchant identifiers or terminal identifiers.
[0057] It should be noted that the transaction metric calculation sub-module 804 of the ATM location assessment server 200 calculates a set of M transaction metrics for each type of transaction. This is carried out by, for example, retrieving global transaction metric data representing a plurality of variables in relation to transactions performed at particular ATMs within the geographical location.
18
[0058] In addition, the survival distribution generation sub-module 806 calculates survival distribution functions (SDFs) for an ATM cluster using transaction metric data of ATMs belonging to the cluster. The calculation can be a univariate analysis of the transaction data performed with respect to a particular transaction metric (e.g. amount of cash withdrawn per day).
[0059] Finally, the score calculation sub-module 808 of the assessment server 200 generates failure probabilities for each ATM cluster using the transaction metric SDFs generated by the survival distribution generation sub-module 806. Failure probabilities are calculated using transaction metric state data (e.g. the expectation of the transaction metric for the cluster when the clusters are derived via the K-means technique). Furthermore, the score calculation sub-module 808 also calculates a score for the location by combining the various failure probabilities.
[0060] Whilst the foregoing description has described exemplary embodiments, it will be understood by those skilled in the art that many variations of the embodiment can be made within the scope and spirit of the present invention.

We Claim:
1. A computer implemented method of assessing a potential location for an automated teller machine (ATM), the method comprising:
receiving, at an ATM location assessment server, transaction data corresponding to transactions in a geographic area including the potential location;
receiving, at the ATM location assessment server, ATM data representing, at least, an indication of a number of automated teller machines in the geographic area including the potential location;
identifying, in a transaction identification module of the ATM location assessment server, one or more transactions represented by the transaction data;
processing, in a transaction metric calculation module of the ATM location assessment server, the identified transactions to generate transaction metric data representing one or more transaction metrics, said transaction metrics being significant to the survival of one or more ATMs within the geographic area, where the survival of an ATM ceases when said ATM rejects a transaction request due to insufficient funds being available at the ATM to complete the requested transaction;
generating, in a survival distribution generation module of the ATM location assessment server, one or more survival distribution functions which model the survival of ATMs within the geographic area including the potential location with respect to the one or more transaction metrics; and
calculating, in a score calculation module of the ATM location assessment server, a location score for the potential location using the one or more survival distribution functions, the location score representing the suitability of the potential location for deploying a new ATM.
2. The method according to claim 1, wherein transactions represented by the transaction data are of a specific type.
3. The method according to either claim 1 or 2, wherein processing the identified transactions to generate transaction metric data includes:
obtaining global transaction variable data representing a set of global transaction variables from which the transaction metrics can be selected;
performing statistical analysis to identify one or more global transaction variables that are significant to the survival of one or more ATMs within the location;
20
selecting one or more global transaction variables as the transaction metrics based on the statistical analysis; and
generating ATM behavior data including transaction metric values that represent one or more behavioral states, where the transaction behavior of each ATM within the geographic area can be represented by the transaction metric values of a state.
4. The method according to claim 3, wherein the set of global transaction variables includes a plurality of global transaction variables selected from:
a. the amount of cash withdrawn per day;
b. the amount of cash withdrawn per day from all ATMs within a predetermined area (relative to the ATM);
c. the number of withdrawal transactions per day;
d. the number of withdrawal transactions per day from all ATMs within a predetermined area (relative to the ATM);
e. the ratio of a/b;
f. the ratio of c/d;
g. the ratio of a/c
h. the ration of b/d;
i. the ratio of g/h
j. the amount of cash withdrawn per day from a particular payment card;
k. the amount of cash withdrawn per day from a particular card and from all ATMs within a predetermined area (relative to the ATM);
l. the number of withdrawal transactions per day from a particular payment card; and
m. the number of withdrawal transactions per day from a particular payment card from all ATMs within a predetermined area (relative to the ATM).
5. The method according to claim 4, wherein the global transaction variable data is obtained from the transaction data, and/or the ATM data, for each ATM within the geographic area.
6. The method according to any one of claims 3 to 5, wherein performing statistical analysis includes applying generalized linear model (GLM) analysis to identify the transaction metrics.
21
7. The method according to any one of claims 3 to 6, wherein generating ATM behavior data includes applying pattern classification or clustering to the transaction metric data of one or more ATMs within the geographic area.
8. The method according to claim 7, wherein K-means clustering is applied to the transaction metric data to produce a predetermined number of ATM clusters, each of said clusters having associated transaction metric state data representing a behavioral state of one or more ATMs within the geographic area.
9. The method according to claim 8, wherein the generation of the one or more survival distribution functions is performed for each of the one or more ATM clusters and using transaction metric data of ATMs belonging to the ATM cluster.
10. The method according to claim 9, wherein the generation of the one or more survival distribution functions includes:
i) processing, in the survival distribution generation module, the transaction data to obtain data values for the transaction metrics of each ATM belonging to the cluster;
ii) censoring the transaction data values of each ATM that do not correspond to the occurrence of a failure event, the failure event being defined as an event which causes the ATM to cease to survive;
iii) performing a univariate analysis of the transaction data in order to process the data with respect to a particular transaction metric;
iv) generating a Survival Distribution Function (SDF) for the ATM cluster using the processed and censored transaction metric data, the SDF being in respect of a particular transaction metric; and
v) repeating at least steps ii) to iv) such that a SDF is produced for each transaction metric.
11. The method according to claim 10, wherein Kaplan-Meier analysis is applied to produce the SDF for each transaction metric.
12. The method according to any one of claims 1 to 11, wherein calculating the location score for the potential location includes generating failure probabilities using the SDFs of each transaction metric.
22
13. The method according to claim 11, failure probabilities are calculated using transaction metric state data representing a behavioral state of one or more ATMs within the geographic area of the potential location.
14. The method according to any one of claims 12 to 13, wherein the location score for the potential location is calculated by generated failure score data representing one or more failure scores for the location, each failure score being generated by combining the failure probabilities according to a weighted sum.
15. The method according to any one of claims 2 to 14, wherein the location score for the potential location is the failure score as generated using transaction data corresponding to transactions of a first type.
16. The method according to any one of claims 2 to 14, wherein the location score for the potential location is generated by combining a plurality of failure scores for the location, each failure score being generated using transaction data representing transactions of corresponding different types.
17. An apparatus for assessing a potential location for an automated teller machine, the apparatus comprising:
a computer processor and a data storage device, the data storage device having a transaction identification module; a transaction metric calculation module; a survival distribution generation module; and a score calculation module comprising non-transitory instructions operative by the processor to:
receiving transaction data corresponding to transactions in a geographic area including the potential location;
receiving ATM data representing, at least, an indication of a number of automated teller machines in the geographic area including the potential location;
identifying one or more transactions represented by the transaction data;
processing the identified transactions to generate transaction metric data representing one or more transaction metrics, said transaction metrics being significant to the survival of one or more ATMs within the geographic area, where the survival of an ATM ceases when said ATM rejects a transaction request due to insufficient funds being available at the ATM to complete the requested transaction;
23
generating one or more survival distribution functions which model the survival of ATMs within the geographic area including the potential location with respect to the one or more transaction metrics; and
calculating a location score for the potential location using the one or more survival distribution functions, the location score representing the suitability of the potential location for deploying a new ATM.