POS-originated transaction traces as a source of contextual information for risk management systems in EFT transactions

Abstract

Transaction traces analysis is a key utility for marketing, trend monitoring, and fraud detection purposes. However, they can also be used for designing and verification of contextual risk management systems for card-present transactions. In this paper, we presented a novel approach to collect detailed transaction traces directly from payment terminal. Thanks to that, it is possible to analyze each transaction step precisely, including its frequency and timing. We also demonstrated our approach to analyze such data based on real-life experiment. Finally, we concluded this paper with important findings for designers of such a system.

1 Introduction

The design and evaluation of new systems, algorithms, and techniques heavily rely on the existence of productive datasets. There are number of papers in the literature that focus on this issue. For example, in [1], one can find comprehensive overview of existing datasets to evaluation of cyclostationarity-based network Intrusion Detection Systems (IDSs), together with their own dataset with real traffic and up-to-date attacks. To the Authors’ best knowledge, there is no such a dataset with transaction data from a payment terminal available that will allow to design and evaluate new solutions in payment ecosystems.

An acronym POS stands for Point-of-Sale: the device that represents the most critical function in a retailer’s supply chain, the checkout process. The cash register is the moment of truth at which the consumer must commit to a purchase and offer tender in exchange for the goods [2]. In the interest of all is to make that process quick, safe, optimal, and comfortable. One of the possible ways to achieve that is to perform extended analysis of data gathered from a POS device and to introduce necessary improvements. This data is an effective source of information about shoppers, their purchases, and behaviors and is commonly used in retail environment for:

• Analysis of purchase trends

• Demand planning and forecasting

• Consumer marketing programs

• Strategic account development

Extensive studies have been conducted by various researchers in that field. For example, authors of [3] emphasized an importance of Point-of-Sale data sharing among suppliers in terms of demand forecasts. On the other hand, the paper [4] points out an impact of POS data inaccuracy and inventory data errors. An thought-provoking way of POS data utilization has been described in [5]. Authors proposed there the way how to track usage patterns of residential pesticides based on those data. As we can see, POS-originated data can be used for various purposes. One of them will be described later in this paper.

From the technical point of view, a POS device usually consists of two physical devices:

• (1) A POS terminal: the main unit, responsible for tracking and recording customer orders, managing inventory, creating printouts, etc.

• (2) A payment terminal: the peripheral, autonomous device responsible for performing electronic transaction. Usually, it is a programmable Personal Identification Number Pad (PIN Pad, without a printer)

In this paper, we are focusing only on data gathered exclusively from a payment terminal. Those data will be presented as a source of contextual information for a dedicated risk management systems.

The rest of this paper is organized as follows: Section 2 provides the technical background to fully understand the consecutive sections, Section 3 describes the performed experiment in details, and Section 4 contains the experimental results, while Section 5 summarizes the paper and maps out future work.

2 Problem formulation and related works

This section formulates the problem and provides the crucial background to understand it in hand. Section 2.1 summarizes the information about card-present transaction and electronic card ecosystem. Section 2.2 presents the current utilization of transaction’s logs collected in various points of the payment system. Section 2.3 describes the concept of context-aware systems and security. Finally, Section 2.4 discloses the usage of contextual risk managements in payment systems and explains the motivation and goal of this paper.

2.1 Card-present transaction overview

Payment card transactions are gaining more and more popularity in each country across the world [6]. Only in Poland, there were more than 1.1 billion transactions performed in Q2.2017 [7]. People are getting used to pay by card instead of paying in cash. They are commonly treating electronic payments as fast and secure way to finalize the transaction. It is because of increasing adoption of chip cards [8] compliant with EMV specification [9]. This standard has been firstly proposed by Europay, MasterCard, and Visa in 1993. Currently, it is promoted by EMVCo which associates all major Payment Card Schemes: Mastercard, Visa, American Express (AmEx), Discover, China UnionPay (CUP), and Japan Credit Bureau (JCB), and covers both contact and contactless payment cards. According to some statistics [9], transaction made with contactless card is 53% faster than a traditional magnetic stripe credit card transaction and 63% faster than using cash. There is also emerging trend observed on the market to emulate contactless payment card with a smartphone [10], thanks to services like Android Pay [11] or Samsung Pay [12] that uses Host Card Emulation technique (HCE) [13] and Near Field Communication (NFC) interface [14]. Thankfully, a smartphone emulating payment card is treated and read by the payment terminal as a physical card, so no changes are required in the payment infrastructure to handle those devices correctly.

Figure 1 presents standard payment card scheme. It involves four parties:

• Cardholder: a person that is buying goods or services at the Point-of-Sale and wishes to pay by card

  Fig. 1

  

  Payment card scheme architecture

• Merchant: a shop that accepts payment cards

• Acquirer: an institution that is responsible for transaction processing and settlement

• Issuer: an institution, usually bank, that issued payment card to the Cardholder

It is worth to mention that payment transaction can be sent from the Acquirer to the Issuer directly (the so-called on-us) or via payment scheme network (Visa/Mastercard, etc.). So, payment organizations may not be aware of all transactions made by certain Cardholder.

Payment transaction compliant with the EMV specification consists of several steps [15]. Figure 2 depicts in details all possible transaction flows that can happen for both contact and contactless cards. The most remarkable steps that have a significant impact on the transaction processing time are Cardholder Verification and Transaction Authorization. The Cardholder can be verified by following Cardholder Verification Methods (CVMs):

• Offline PIN: verified by the card, only for contact EMV

  Fig. 2

  

  Transaction’s flow diagram

• Consumer Device CVM (CDCVM): verified by the device, only for HCE transactions

• Online PIN: verified by the Issuer

• Signature: verified by the Merchant

• No CVM: no verification at all

On the other hand, transaction can be authorized in following way:

• Online: by sending an authorization request to the Issuer

• Offline: locally, by the card

The decision which Cardholder Verification Method and authorization method should be used is being made based on terminal’s configuration and data retrieved from the card (encoded on the card by the Issuer during its personalization phase). Those parameters are for example:

• Cardholder Verification Limit (CVL), only for contactless transactions, the amount above which the Cardholder must be verified: currently 50 PLN in Poland

• Floor Limit, the amount above which the transaction must be authorized online

2.2 Payment transaction traces analysis

As one can easily see in Fig. 1, there are three points, where transaction traces can be collected and analyzed: by Merchant, Acquirer, and Issuer. In Section 1, we described what can be done with transaction data collected by the Merchant. This information is rich; it contains payment credentials, content of the basket for particular transaction, some loyalty information, and so on. In this section, we are focusing on transaction traces that can be collected by Acquirer and Issuer. Usually, those traces contain only pure payment-related information without any details about Cardholder or content of the basket. Transaction traces at the level of Acquirer can be used only for statistical purposes. We must note that an Acquirer is not aware of all transaction made by some Cardholder, but only of those performed by the Acquirer’s terminal. On the other hand, transaction traces from the Issuer contain information about all transactions made by the Cardholder. Therefore, this data is profitable and worthwhile for various purposes [16]:

• Law enforcement: Law enforcement agencies can subpoena records from the credit card Issuer to find out the time, date, and place of a credit card purchase, in other words information that may be helpful in determining the last known location of a crime victim or suspect. National security agencies also track terrorist activity by monitoring certain purchases.

• Marketing: Issuers use past purchasing patterns as a basis for offering additional products. Someone purchasing airline tickets with their credit card may get offers of airline rewards credit cards or travel-related services from the Issuer or an affiliate.

• Risk management: Cardholders who continually go over their credit limits or exhibit unusual spending habits (such as charging large amounts of merchandize on a card they had previously rarely used) may be at greater risk of not paying their bills or filing for bankruptcy.

• Fraud detection: Credit card companies and Issuers monitor spending to detect unusual purchasing habits that could be red flags for fraud. This topic is quite popular across researchers. There are plenty of fraud detection systems proposed in the literature that incorporate various data mining techniques like neural network [17, 18], outlier detection [19], data clustering [20], support vector machine [21], artificial immune system [22], self-organizing maps [23–25], hidden Markov model [26], Bayesian classifier [27], fuzzy systems [28], and genetic algorithm [29]. Some of them has been tested using real transaction traces gathered, e.g., from a bank from UK [30, 31].

2.3 Context-aware systems and security

According to the Dictionary [32], context can be defined as follows: context is the set of circumstances or facts that surround a particular event, situation, etc. In other words, it can be described as a set of information about the entity in particular moment in time. An author of [33] divided contextual information into two parts:

• Internal, which describes user state such as emotions, look, and history of life

• External, which refers to environment states such as time, location, and temperature

The utilization of contextual information for various solutions in a very popular topic among researchers. They started to propose the so-called context-aware systems. Those systems can adapt their operations to the current context without explicit user intervention and thus aim at increasing usability and effectiveness by taking environmental context into account [34]. An example of such a system can be a solution proposed in [35]. Authors extended the instant messaging paradigm by adding context awareness to support information management within a hospital. All users (in this case nurses, physicians, etc.) are equipped with mobile devices to write messages that are sent when a desired set of conditions are met. For example, a user can formulate a message that should be dispatched to the first doctor that enters room number 110 after 6 am. Such a system is aware of following contextual elements: time, roles, location, and device state.

Another group of context-aware systems concerns various security services, like access control, encryption (information confidentiality), and authentication. They are known in the literature as context-aware security systems [36]. For example, authors of [37] proposed the solution for mobile ad hoc networks that analyzes various contextual information, such as communication channel status, battery status, and weather condition, and then uses them to determine whether the misbehavior is likely a result of malicious activity or not. Other examples of context-aware security (in terms of access control) can be found in [38–40].

Context-aware systems are usually capable to deal with special types of context and are tailored and optimized to operate in specific conditions, e.g., in hospital scenarios or ad hoc networks. Unfortunately, they do not have to be flexible and extensible. To simplify the development of context-aware applications, researchers started to propose the so-called context-aware frameworks [41]. An abundant overview of such frameworks can be found in [34].

In the next section, we will present how context-aware systems can be utilized during card-present transactions.

2.4 Contextual risk management in EFT systems

As mentioned in Section 2.1, card-present transactions can have plenty possible scenarios. The way how the transaction is being processed depends on various factors: transaction amount, card used, data stored on the card, and terminal’s configuration. We can say that transaction processing rules are constant for every transaction: it means that each Cardholder is treated equally, no matter what is his history and the context of current transaction. There are also clear rules regarding risk related to the transaction. If a disputed transaction has been authorized:

• With signature verification, then it would be charged to the merchant.

• With PIN verification, then it would be charged to the customer.

• By the card (Offline Authorization), it would be charged to issuing bank.

Such an approach is effortless, but it causes that a lot of transactions are processed “time and user experience-ineffectively” [42]. One can imagine that the transaction flow could be tailored to the Cardholder and to the particular transaction, based on various contextual factors. It may give a lot of profits, e.g., better user experience, greater Cardholder’s loyalty, and shorter transaction processing time. It should also assure acceptable level of transaction security. This is the main motivation why contextual risk management systems started to appear. They enable merchants to take some risk by allowing some payment transactions being authorized, for example, without any verification in exchange for the abovementioned profits. Such systems could be very useful on the markets, where the level of fraudulent transactions is low. For instance, such an information can be found in the European Central Bank’s report [43], which says that the level of deceptions is very low in certain countries.

The topic of contextual risk management was already considered in our earlier papers. It was firstly discussed in [44], where we proposed a new Cardholder Verification Method which is One-time PIN verification. This method assumes that each transaction is authorized online and the decision if PIN verification should be performed is being made by the Issuer based on various contextual factors (like Cardholder’s reputation, place, and time of the transaction). In the case of positive decision, encrypted PIN (or One-time PIN) is being sent to the terminal and a payment application verifies, if the encrypted PIN entered by the Cardholder is the same as the one received from the Issuer. This paper proposed only a modification of current payment system architecture but did not suggest any decision making algorithm.

Another approach has been discussed in [45], where we proposed the dedicated solution for great merchants (such as Carrefour and Auchan), where historical transaction data are kept on merchants’ servers. The proposed architecture (depicted in Fig. 3) assumed that payment terminal sends contextual information (the tokenized card’s number, transaction’s amount, merchant’s location, etc.) to the merchant’s server and it receives back the decision whether the transaction should be authorized “offline” or “online”. We also proposed a simple example of the algorithm that calculates floor limit for current transaction based on the transactions’ periodicity factor, transactions’ amount stability factor, and Cardholder’s reputation. However, the quoted reputation system has a few flaws; for example, it is not possible to detect the situations where:

• The Cardholder enters the Offline PIN with success in the second attempt. Such a transaction is treated the same as that with PIN verified on the first try.

  Fig. 3

  

  Contextual risk management system architecture

• He cancels the transaction on PIN entry screen. Such a behavior is suspicious, but it is not taken into account at all.

• A transaction with Online PIN that has been declined because of lack of funds (but PIN has been verified correctly). Such a situation should increase Cardholder’s reputation, because the key information for the system is that the Cardholder knew the PIN code, but it works against it.

To extend and improve such a situation, in the paper [42], we proposed a new Cardholder’s reputation system that can be utilized in contextual risk management solutions for payment transactions. This reputation system covers all possible transaction flows. Each transaction flow has constant rating assigned to it. The set of ratings for all possible transaction flows are parameters of the reputation system. The Cardholder’s reputation for a forthcoming transaction n can be calculated as weighted average of the last N transactions limited to the range <R_MIN,R_MAX>, see Eq. (1). N, R_MIN, and R_MAX are parameters of the reputation system.

$$ R_{n} = \left\{ \begin{array}{ll} R_{\text{MIN}} & \text{if } \overline{R}_{n-i} < R_{\text{MIN}}\\ \overline{R}_{n-i} & \text{if } \overline{R}_{n-i} \in \langle R_{\text{MIN}},R_{\text{MAX}}\rangle\\ R_{\text{MAX}} & \text{if } \overline{R}_{n-i}>R_{\text{MAX}}\\ \end{array} \right.,\: $$

(1)

The proposed reputation system assumed that there must be at least N historical transaction stored in the system’s database to calculate proper reputation value; otherwise, Cardholder’s reputation is set to 0. Equation (2) shows the proposed formula how to calculate weights for the weighted average computation.

$$ w_{Rni}={\frac{1}{2}}{e^{-\frac{t_{n}-t_{i}}{\tau_{RT}*AvgT}}}*\text{erfc}\left(\frac{(n-i-1)*2}{x_{d}}+x_{m}\right)\;, $$

(2)

where n is the index of current transaction, i is the index of ith transaction, t_n is the time of current transaction, t_i is the time of ith transaction, AvgT is the average distance (in time, measured in days) between transactions, τ_RT is the reputation system parameter (the decay factor), erfc is the complementary error function, x_d is the reputation system parameter (a dispersion parameter of the erfc function), and x_m is the reputation system parameter (a concentration parameter of the erfc function [46]).

Every presented approach is focusing only on internal part of contextual information. Comprehensive contextual risk management system should be able to take into account external part of contextual information. This is the subject of our future research.

All of mentioned papers presented various enhancements for current card payment ecosystem; however, all of them were tested using synthetic sets of data (prepared based on experts’ knowledge), because of the lack of realistic production data. To our best knowledge, there is no solution known from the literature that describes a way how the traces directly from a payment terminal can be created, collected, and analyzed for risk management system’s improvement.

In this paper, we present our approach to gather and analyze transaction traces collected directly from a payment terminal. Thus, in Section 3, we describe our experiment performed on large-scale production data. In Section 4, we present key results of the experiments and we show what useful information can be extracted in terms of design and configuration of the contextual risk management system.

3 The experiment

To conduct our experiment, we performed several steps, which are presented in the following sections.

3.1 Design and implementation of application’s extension

We designed and implemented an extension to the existing payment application that allows it to record detailed information about each transaction. During the transaction, payment application records all important data and events related to the given transaction and stores it as an entry in transactions’ traces batch file.

Table 1 presents the structure of one entry in the mentioned batch, while Table 2 lists all possible events that can be included in the trace. Figure 4 shows an example transactions’ traces batch. Such a structure of a batch’s entry has a few advantages:

• (1) There is a possibility to measure how long it took the Cardholder to enter PIN code, place a signature, etc.

  Fig. 4

  

  Example transactions’ traces batch

  Table 1 Structure of single transaction’s trace

  Table 2 Possible events to be recorded in transaction’s trace

• (2) It is possible to detect the situation when the transaction was interrupted by the user, for example, by canceling the PIN entry.

Such an information would not be possible to retrieve from other viewpoint, e.g., from the Acquirer or the Issuer perspective.

The essential thing in the batch’s entry is that we are using card’s token to unambiguously identify certain payment card without revealing its Primary Account Number (PAN). The way how a token is calculated is fully compliant with Payment Card Industry (PCI) requirements [47], and it looks as follows:

$$ {\text{token}} = \mathrm{SHA256}\left(\mathrm{ {PAN} | {EXP\_DATE} | {SSS}}\right) $$

(3)

where:

• EXP_DATE: expiry date of the payment card

• SSS (Strong Secret Salt): securely distributed across all terminals set of constant 32 bytes

Thanks for that, the batch of transactions’ traces:

• (1) Can be processed in systems that are not PCI DSS (Payment Card Industry Data Security Standard) certified, because the batches do not contain sensitive data

• (2) Contains card’s token, which is only the pseudonym in terms of General Data Protection Regulation (GDPR) [48].

The GDPR is the European Union (EU) regulation that will take effect on May 25, 2018. It offers a new framework for data protection with increased obligations for organizations, and its reach is far and wide. The GDPR is applicable to any organization that intentionally offers goods or services to the European Union or that monitors the behavior of individuals within the EU. The GDPR defines pseudonymization as “the processing of personal data in such a way that the data can no longer be attributed to a specific data subject without the use of additional information” [49]. Moreover, the Regulation says that if it is possible to demonstrate that the System is not in a position to identify the data subject (presented case), Articles 15 to 20 shall not apply. Those Articles contain regulations about:

• Right of access by the data subject

• Right to rectification

• Right to erasure (“right to be forgotten”)

• Right to restriction of processing

• Notification obligation regarding rectification or erasure of personal data, or restriction of processing

• Right to data portability

In other words, it would be much more easier to meet GDPR requirements after productive rollout of the system, thanks to the utilization of pseudonymization. Additionally, the GDPR provides an exception to the purpose limitation principle for data processing for scientific, historical, and statistical research; pseudonymization is sufficient to meet its requirements, so similar experiments in the future are possible.

3.2 Data collection

Each payment terminal in the field is managed remotely by the central system called terminal management system (TMS). It is responsible for the management of terminal’s configuration, monitoring its internal state, etc. Most of TMSs have an ability to receives some files from the terminal. Usually, a payment terminal is connecting to its TMS once a day. Because transactions’ traces batch is a single text file, we made a change in the payment application, so that the whole file was uploaded to the TMS each day.

3.3 Data analysis

Once transactions’ traces batches has been collected, they must be analyzed somehow. In [50], one can find an extensive overview of currently available tools and utilities that are widely used by researched to data analysis and statistics.

We started our analysis from designing the database to store transactions’ traces (see Fig. 5). Then, we created dedicated Python’s script that can parse collected traces and that inserts data to the database. Finally, we created a set of Python’s scripts to analyze collected data. We utilized the following libraries:

• Pandas: the library providing high-performance, easy-to-use data structures and data analysis tools for the Python [51]

  Fig. 5

  

  Structure of database to store collected traces

• NumPy: fundamental package for scientific computing with Python [52]

• Matplotlib: plotting library for Python [53]

To write our scripts and to test them effectively, we used IPython [54], which is the system for interactive scientific computing allowing, for example, to execute certain parts of Python’s code independently, without loss of the whole context (currently read data, variables, etc.). We also used Jupyter [55], which is a comfortable IDE (Integrated Development Environment) to write and execute IPython’s code easily.

3.4 Experiment’s details

Our experiment lasted 5 months. We uploaded our modified payment application onto 68 terminals located in 18 shops belonging to one of the retail chain. All those shops are in North-West region of Poland, near the border with Germany. During this period, we collected 1,048,382 transactions’ traces.

4 Experiment’s results

Results of our experiment can be divided into the following groups.

4.1 Analyses of transactions’ amount and time

We performed several analyses concerning transactions’ amount and time, considering precise transaction time, card used, etc. Such an information can be useful for proper configuration of contextual risk management system, for example, by focusing mostly on frequently used cards or by adjusting risk management parameters in time, according to the present number of transactions. Because of limited space in this paper, we are presenting the most noteworthy findings from the results.

Figures 6 and 7 illustrate our analysis for weekdays. The first one presents the quantity of transactions performed in time with a breakdown per card used, while the second one shows average transaction amount for all cards with a breakdown per card used. From those pictures, we can see that:

• There are around two to three times more transactions made with contactless EMV cards than those made with contact EMV cards.

  Fig. 6

  

  Quantity of transactions in time with a breakdown per card type, during weekdays

  Fig. 7

  

  Average transaction amount in time with a breakdown per card type, during weekends

• The level of other card types (contactless magstripe and magstripe) is insignificantly low.

• Customers are using contact EMV cards for high-value transactions. The average transaction amount for contact EMV cards is more than two times higher than that for contactless EMV cards.

• The highest frequency of transactions is between 15:30 and 18:30. There is around three times more transactions in this period than in the mornings.

Then, we did analogous analysis for weekends. Based on Figs. 8 and 9, we can see that:

• The ratio of transactions made with contactless EMV cards to that made with Contact EMV cards is comparable to weekdays.

  Fig. 8

  

  Quantity of transactions in time with a breakdown per card type, during weekends

  Fig. 9

  

  Average transaction amount in time with a breakdown per card type, during weekends

• The level of other card types (contactless magstripe and magstripe) is still insignificantly low.

• The average transaction amount in time looks similar for weekends and for weekdays.

• Most transactions during weekends are made around midday and in the evenings.

4.2 Analysis of transactions’ processing time

Figure 10 presents the transaction processing time of all examined transactions. As we can see, majority of transaction lasts for about 5–6 s, but still, there are plenty transactions with processing time around 10 s. Of course, it depends on various factors: card used, authorization method, Cardholder Verification Method, etc. On the other hand, Fig. 11 shows transaction processing time of transactions with PIN verification. In such a situation, it usually takes around 10 s to authorize the transaction.

Fig. 10

Processing diagram of all transactions

Fig. 11

Processing diagram of transactions with PIN verification

Next, we will scrutinize possible gain of time that can be accomplished by incorporating contextual risk management system that increases CVL limit dynamically. Figures 12 and 13 present the theoretical maximal gain of time if CVL limit will vary from 0PLN to 200PLN, for all types of transactions and for contactless transactions, respectively. One must note that there is an inflection point at the level of 50PLN, because CVL limit for contactless transaction in Poland is equal to that amount. From those figures, we can see a few interesting regularities, for example:

• 1. By making CVL limit for contact transactions equal to that for contactless transactions (50PLN), we could gain more than 200 h (around 12,000 min).

  Fig. 12

  

  Theoretical gain of time depending on CVL limit for all types of transactions

  Fig. 13

  

  Theoretical gain of time depending on CVL limit for contactless transactions

• 2. By increasing CVL limit only for contactless transactions to 70PLN, we could gain more than 117 h (above 7000 min).

As we can see, even a small change in the CVL limit will bring benefits related to the processing time of the transaction.

4.3 Analysis of transactions’ traces

Table 3 presents collected transactions’ traces together with their quantities. The majority of transactions are processed without any Cardholder Verification and are authorized online. There are also three frequently happening transactions: Online Authorization with Online PIN verification, Offline Authorization without Cardholder Verification, and Online Authorization with Offline PIN verification. The level of other transactions’ flows is negligibly low. It is really an important observation from a designer’s contextual risk management system point of view. He can decide, for example, to ignore other transactions’ flows and focus his algorithms to work only for commonly happening transactions. Such a simplification can have positive impact on performance of whole system and on cost of its implementation.

Table 3 Transactions’ traces collected during experiment

4.4 Analysis of clients’ loyalty

During our experiment, we collected transaction traces for 189,898 unique card tokens. Figure 14 presents how many card tokens has been used to perform certain number of transactions. As we can see, almost 40% (73,229 pcs.) of unique tokens performed only one transaction. Two transactions have been performed by more than 16% (30,577 pcs.) tokens and so on. In our opinion, such a situation could happen because:

• The experiment has been conducted in Poland, near the Polish-German border, where there are a lot of tourists visiting this area and buying things occasionally.

  Fig. 14

  

  Number of clients that performed certain number of transactions

• Nowadays, majority of Cardholders are using more than one payment card. From the designer’s contextual risk management system perspective, it is worth to foresee the development of some web service where customers can log-in and link several payment cards to one account (for loyalty purposes) and design his system to operate on the level of a client rather than on pure token.

Despite the previous results, we observed quite a big set of loyal clients. We denoted loyal client a person, who performed at least 10 payment transactions using his card during our experiment. It turned out that there were 21,125 tokens with such many performed transactions, what is more than 10% of all cards. After that, we checked the proportions of loyal clients in certain stores. Figure 15 shows the number of loyal clients per store. As we can see, the level of loyalty across the stores varies. It is a good source of information that can help to prepare effective marketing strategy. The sum of all presented tokens is 19,042; it means that generally, loyal customers of one retail chain are usually making their transaction in one store.

Fig. 15

Number of loyal clients (that made more than 10 transactions), per store

5 Conclusion and future work

Transaction traces collected in various points of payment ecosystem are a valuable source of information for diverse analyses. In this paper, we introduced our approach to collect transaction traces at the level of payment terminal, which can inspire a new field of research. We also described our proposition how to evaluate those data with currently available tools and techniques. After that, we presented our experiment which involved the following: performance of changes in productive payment application, data collection, and its analysis. Based on the results of the experiment, we formulated important recommendations, especially for designers of contextual risk management systems for payment transactions, such as

• (1) Design your system only for contact EMV and contactless EMV cards. The level of rest of the cards is negligibly low (see, e.g., Fig. 6).

• (2) Design your system to be able to operate differently, depending on current time and day of the week.

• (3) It is worth to design such a system even for small increase of CVL Limit (see Section 4.2).

• (4) Design your reputation system to handle only most common transaction flows (see the level of other transaction flows in Table 3).

• (5) Design your system to operate on a client level, not on a card token level (see Section 4.4).

• (6) Perform analogous trial before configuring and launching such a system in new location.

It is worth to mention that gathered productive data can act as reference dataset for design and simulation of similar systems and solutions.

In future work, we would like to create an engine to simulate decision making algorithms from the contextual risk management systems, especially to validate and customize an algorithm proposed in [42]. Moreover, it would be valuable to perform an analogous experiment in a different region of the country, which is not impacted by many occasional consumers and tourists.