阅读说明：本技术 用于无pin的非接触式支付卡授权的基于花费简档的交易值限制 (spending profile-based transaction value limiting for PIN-less contactless payment card authorization ) 是由 D·萨德利尔 于 2018-04-11 设计创作，主要内容包括：支付账户交易的记录被存储。所有交易都与某类商家有关并且由同一账户持有人执行。从账户持有人接收对于针对与该类商家中的商家的交易进行非接触式支付账户交易的请求。基于所存储的交易记录,关于请求执行离群值检测分析。根据分析的结果,确定是否需要为所请求的交易进行PIN输入。(A record of the payment account transaction is stored. All transactions are associated with a certain type of merchant and are performed by the same account holder. A request is received from an account holder to conduct a contactless payment account transaction for a transaction with a merchant in the merchant. Performing an outlier detection analysis with respect to the request based on the stored transaction records. Based on the results of the analysis, it is determined whether PIN entry is required for the requested transaction.)

1. A method, comprising:

Storing a record of a first plurality of payment account system transactions, all of which are related to a first type of merchant and all of which are performed by an account holder;

Receiving a first request from the account holder for a contactless payment account system transaction at a first merchant of the first class of merchants;

Performing a first outlier detection analysis with respect to the first request based on the stored record of the first plurality of payment account system transactions;

determining whether PIN (personal identification number) input is required with respect to the first request based on a result of the first outlier analysis;

Storing a record of a second plurality of payment account system transactions, all related to a second type of merchant and all performed by the account holder, the second type of merchant being different from the first type of merchant;

receiving a second request from the account holder for a contactless payment account system transaction at a second merchant of the second class of merchants, the second merchant being different from the first merchant;

performing a second outlier detection analysis with respect to the second request based on the stored record of the second plurality of payment account system transactions;

Determining whether PIN entry is required with respect to the second request based on results of the second outlier analysis;

storing a record of a third plurality of payment account system transactions, all of which are related to a third type of merchant and all of which are performed by the account holder, the third type of merchant being different from the first and second types of merchants;

receiving a third request from the account holder for a contactless payment account system transaction at a third merchant of the third class of merchants, the third merchant being different from the first and second merchants;

Performing a third outlier detection analysis with respect to the third request based on the stored record of the third plurality of payment account system transactions; and

Determining whether PIN entry is required with respect to the third request based on results of the third outlier analysis.

2. The method of claim 1, wherein:

The first outlier detection analysis uses a first outlier detection model; and

The second outlier detection analysis uses a second outlier detection model that is different from the first outlier detection model.

3. The method of claim 2, wherein:

the first outlier detection model is a gaussian model; and

The second outlier detection model is a log-normal model.

4. The method of claim 3, wherein the Gaussian model employs a threshold number based on one of: (a) a sigma calculation; (b) a half sigma calculation; and (c) two sigma calculations.

5. The method of claim 1, wherein:

The first category of merchants are fast food restaurants;

The second type of merchant is a supermarket; and

a third category of merchants are department stores.

6. the method of claim 1, wherein the records of the first, second, and third plurality of payment account system transactions are stored in a computer operated by an operator of a payment account system.

7. The method of claim 1, wherein the records of the first, second, and third plurality of payment account system transactions are stored in a computer operated by an issuer of an account holder's payment system account.

8. The method of claim 1, wherein the account holder is a first account holder;

The method further comprises the following steps:

Storing a record of a fourth plurality of payment account system transactions, all of which are related to the first type of merchant and all of which are performed by a second account holder, the second account holder being different from the first account holder;

Receiving a fourth request from the second account holder for a contactless payment account system transaction at a fourth merchant of the first class of merchants, the fourth merchant being different from the first, second, and third merchants;

performing a fourth outlier detection analysis with respect to the fourth request based on the stored record of the fourth plurality of payment account system transactions;

determining whether PIN entry is required with respect to the fourth request based on results of the fourth outlier analysis;

storing a record of a fifth plurality of payment account system transactions, all of which are related to the second type of merchant and all of which are performed by the second account holder;

Receiving a fifth request from the second account holder for a contactless payment account system transaction at a fifth merchant of the second class of merchants, the fifth merchant being different from the first, second, third, and fourth merchants;

Performing a fifth outlier detection analysis with respect to the fifth request based on the stored record of the fifth plurality of payment account system transactions;

Determining whether PIN entry is required with respect to the fifth request based on results of the fifth outlier analysis;

Storing a record of a sixth plurality of payment account system transactions, all of which are related to the third type of merchant and all of which are performed by the second account holder;

Receiving a sixth request from the second account holder for a contactless payment account system transaction at a sixth merchant of the third class of merchants, the sixth merchant being different from the first, second, third, fourth, and fifth merchants;

performing a sixth outlier detection analysis with respect to the sixth request based on the stored record of the sixth plurality of payment account system transactions; and

Determining whether PIN entry is required with respect to the sixth request based on results of the sixth outlier analysis.

9. the method of claim 1, wherein the contactless payment transaction at the first merchant is initiated using a payment-enabled mobile device.

10. the method of claim 1, wherein the contactless payment transaction is initiated at the first merchant using an IC (integrated circuit) payment card.

11. A method, comprising:

Storing a record of a plurality of payment account system transactions, all relating to a class of merchants and all performed by an account holder;

receiving a request from the account holder for a contactless payment account system transaction at a merchant of the class of merchants;

performing an outlier detection analysis with respect to the request based on the stored records of the plurality of payment account system transactions; and

Based on the results of the outlier analysis, a determination is made as to whether PIN (personal identification number) entry is required for the request.

12. The method of claim 11, wherein the outlier detection analysis uses an outlier detection model.

13. The method of claim 12, wherein the outlier detection model is a gaussian model.

14. The method of claim 13, wherein the gaussian model employs a threshold number based on one of: (a) a sigma calculation; (b) a half sigma calculation; and (c) two sigma calculations.

15. The method of claim 12, wherein the outlier detection model is a log-normal model.

16. An apparatus, comprising:

A processor; and

A memory device in communication with the processor, the memory device storing program instructions, the processor operable with the program instructions to perform functions of:

storing a record of a plurality of payment account system transactions, all relating to a class of merchants and all performed by an account holder;

Receiving a request from the account holder for a contactless payment account system transaction at a merchant of the class of merchants;

Performing an outlier detection analysis with respect to the request based on the stored records of the plurality of payment account system transactions; and

based on the results of the outlier analysis, a determination is made as to whether PIN (personal identification number) entry is required for the request.

17. The apparatus of claim 16, wherein the outlier detection analysis uses an outlier detection model.

18. The apparatus of claim 17, wherein the outlier detection model is a gaussian model.

19. the apparatus of claim 18, wherein the gaussian model employs a threshold number based on one of: (a) a sigma calculation; (b) a half sigma calculation; and (c) two sigma calculations.

20. The apparatus of claim 17, wherein the outlier detection model is a log-normal model.

background

Fig. 1 is a block diagram illustrating a conventional payment system 100.

The system 100 includes a conventional payment card/device 102. As will be familiar to those skilled in the art, the payment card/device 102 may be a magnetic stripe card, an IC (integrated circuit) card, a key fob, a payment-enabled smartphone, or the like. The payment card/device 102 is shown carried and used by an account holder/user 103.

the system 100 also includes a reader component 104 associated with the POS terminal 106. In some known manner (depending on the type of payment card/device 102), the reader component 104 is able to read payment account numbers and other information from the payment card/device 102.

The reader assembly 104 and POS terminal 106 may be located in a room of a retail store and operated by a sales person of the retailer to process the retail transaction. The payment card/device 102 is shown in fig. 1 as interacting with the reader assembly 104 and the POS terminal 106 in order to perform such transactions.

A computer 108 operated by an acquirer (acquiring financial institution) is also shown as part of the system 100 in fig. 1. Acquirer computer 108 may operate in a conventional manner to receive authorization requests for transactions from POS terminal 106. The acquirer computer 108 may route the authorization request to a server computer 112 operated by an issuer of a payment account associated with the payment card/device 102 via the payment network 110. As is also well known, the authorization response generated by the payment card issuer server computer 112 may be routed back to the POS terminal 106 via the payment network 110 and the acquirer computer 108.

one well-known example of a payment network is known as the "Banknet" system and is operated by Mastercard International Incorporated as its assignee.

the payment account issuer server computer 112 may be operated by or on behalf of a financial institution ("FI") that issues payment accounts to individual users. For example, the payment account issuer server computer 112 may perform functions such as: (a) receiving and responding to an authorization request for a payment account transaction charged for a payment account issued by the FI; (b) tracking and storing transactions and maintaining account records; (c) presenting a periodic account statement; (d) receiving and tracking payment made by an account holder to an issuer; and (e) clearing the transaction.

the components of the system 100 as depicted in fig. 1 are only components that are required to process a single transaction. A typical payment system can handle many purchase transactions (including simultaneous transactions) and can include a significant number of payment account issuers and their computers, a significant number of acquirers and their computers, as well as numerous merchants and their POS terminals and associated reader components. The system may also include a very large number of payment account holders carrying payment cards or other devices for initiating payment transactions by presenting the associated payment account numbers to a reader component of the POS terminal.

Referring again to payment card/device 102 and reader component 104, some conventional types of interactions between those devices will now be described in more detail.

if payment card/device 102 is a magnetic stripe card, it may be the case that a magnetic stripe portion (not separately shown) is stroked over a card stripe read slot (not separately shown) on reader component 104 so that reader component 104 can read card data magnetically stored on the magnetic stripe.

if the payment card/device 102 is an IC card, there are two well known ways to present the card to the reader. If the card is of the "contact" type, it has conductive contacts on the front side of the card. The portion of the card having the contacts may be inserted into a chip reading slot in the reader component 104 to allow an electrically conductive signal path to be established between the card chip (i.e., the IC on the card) and the electronic components of the reader component 104 via the contacts on the card.

If the card is of the "contactless" type (some cards support both contact and contactless operation), the card includes a loop antenna or the like to support the exchange of short range radio communications to enable data exchange between the card and the reader assembly 104. In practice, the card may be brought into close proximity to, or tapped at, a designated location on a housing (not separately shown) of the reader assembly 104 to allow short-range radio communication between the reader assembly 104 and the card.

If the payment card/device 102 is a payment-enabled mobile device, it is typically configured to emulate the functionality of a contactless IC payment card. In this case, the payment-enabled mobile device may be tapped at a designated location on the reader housing to again allow for the exchange of short-range radio communications.

Similarly, if the payment card/device 102 is a key fob or similar device, it may again emulate the functionality of a contactless IC payment card.

one advantage of the contactless interaction between the payment card/device 102 and the reader component 104 is that corresponding payment account transactions can be completed very quickly and efficiently. However, concerns over contactless transaction security tend to be traded off against speed and convenience. For many merchant locations, the trade-off is achieved by requiring the user/account holder 103 to enter a PIN (personal identification number), but only for transactions that exceed a certain set amount of money, such as 25.00 or 50.00.

The present inventors have now recognized an opportunity to improve the trade-off between speed/convenience on the one hand and security of transactions on the other hand in relation to contactless payment account transactions.

Drawings

The features and advantages of some embodiments of the present disclosure, and the manner of attaining them, will become more apparent when the following detailed description of the disclosure is taken in conjunction with the accompanying drawings, which illustrate preferred and exemplary embodiments, and which are not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram illustrating a conventional system for processing a purchase transaction at a point of sale using a payment account.

Fig. 2 is a block diagram of a payment system according to some embodiments.

Fig. 3 is a schematic plan view of a conventional contactless IC payment card that may be used as a payment device in the system of fig. 2.

FIG. 4 is a simplified block diagram illustration of a conventional payment-enabled mobile device that may be used as the payment device in the system of FIG. 2.

FIG. 5 is a block diagram representation of a computer that may be used as a component of the system shown in FIG. 2.

Fig. 6 is a flow chart illustrating aspects of the present disclosure.

fig. 7 and 8 are diagrams illustrating aspects of outlier detection processing that may be applied to contactless payment transactions, according to aspects of the present disclosure.

Fig. 9 is a flow chart illustrating aspects of the present disclosure.

Detailed Description

in general, and for purposes of introducing concepts of embodiments of the present disclosure, a threshold for determining whether a PIN needs to be entered in a contactless payment account transaction may be determined based on records of account-holders by account-holder and merchant-by-merchant categories to which account holders spend habits. The threshold may be based on an outlier (outlier) detection analysis for detecting specific transactions where the customary spending pattern relative to the account holder is an outlier.

Fig. 2 is a block diagram of a payment system 200 according to some embodiments. The payment system 100 may be very similar to the conventional payment system 100 described above in connection with fig. 1, except for certain modifications described herein.

fig. 2 again shows the user/account holder 103. In this case, the payment device 102 carried by the user 103 is assumed to be one of the above-mentioned types of devices by which contactless payment account transactions are performed at the point of sale. Thus, the payment device 102 is shown in short-range radio communication with the reader device 104a at 201. The reader device 104a may differ from the corresponding conventional components shown in fig. 1 only in that the reader device 104a may not be programmed to enforce a fixed transaction amount threshold that requires PIN entry, if any. Typically, the reader device 104a may include a PIN entry keypad that is not separately shown. As will be seen, in some embodiments, the reader device 104a may be programmed to enforce a predetermined standard threshold on PIN entry for some transactions, but not for others, which may depend on prompts received via messaging from one or more remote computers.

The payment system 200 may also include a POS device 106 connected to the reader device to receive payment account information input to the POS device 106 from the payment device 102 via the reader device 104 a. In arrangements where the POS device, rather than the reader device, will enforce a PIN entry transaction amount threshold, the POS device may be modified in the same manner as described in the preceding paragraph with respect to the reader device 104 a.

As described in connection with fig. 1, payment system 200 may also include acquirer computer 108 and issuer computer 112. In some embodiments, the issuer computer 112 may instead be the issuer computer 112a, i.e., modified in a manner described below. In addition, the payment system 200 includes a payment network 110a, the payment network 110a being modified to communicate with or incorporate a transaction control server computer 202, the transaction control server computer 202 being part of the payment system 200 and provided in accordance with aspects of the present disclosure. As will be described in further detail below, the transaction control server computer 202 may store a record of the payment account transaction and perform an outlier detection analysis on the new contactless payment account transaction request to determine whether a PIN should be required to be entered for the new transaction request.

Fig. 3 is a schematic plan view of a conventional contactless IC payment card that may be used as the payment device 102 in the system of fig. 2.

Referring to fig. 3, in this embodiment, the payment device 102 has a support structure 302 defining a card-shaped body. The card-shaped body may be formed of plastic or other suitable material. For example, the card-shaped body has a size defined for a standard card called "ID 1" in ISO/IEC standard 7810 issued by the international organization for standardization (ISO).

In this embodiment, payment device 102 also includes IC 303 and antenna 306. Antenna 306 may be coupled to IC 303 at connection points 308 and 310.

The antenna 306 may be mounted in, embedded in, and/or supported by the card-shaped body. As shown, the antenna 306 may include several loops arranged along the periphery of the card-shaped body. Alternatively, the antenna 306 may be of a different type and/or configuration.

IC 303 may include suitable circuitry for storing payment account data and related data typically stored in a payment device, as well as circuitry for data communication with a contactless reader device via antenna 306.

fig. 4 is a simplified block diagram illustration of a conventional payment-enabled mobile device that may be used as the payment device 102 in the system of fig. 2. For ease of discussion of fig. 4, the payment device 102 shown therein will alternatively be referred to as a "mobile device 102".

To some extent, it will be assumed in the following discussion, but not limited to, that mobile device 102 is a smartphone.

Mobile device 102 may include a housing 403. In many embodiments, the front of the housing 403 is primarily comprised of a touch screen (not separately shown) that is a key element of the user interface 404 of the mobile device 102.

mobile device 102 also includes mobile processor/control circuitry 406, which is contained within housing 403. One or more storage/memory devices (reference numeral 408) are also included in the mobile device 102. The storage/memory device 408 is in communication with the processor/control circuitry 406 and may contain program instructions to control the processor/control circuitry 406 to manage and perform various functions of the mobile device 102. It is well known that a smart phone can actually function as a pocket-sized personal computer by being programmed with a number of applications or "apps" and a mobile Operating System (OS). (application is represented at block 410 of FIG. 4, and may be stored in practice in block 408 along with other programs to program the processor/control circuitry 406.) A wallet app411 is also shown in FIG. 4. Wallet app411 is shown separately from the other apps represented at block 410, in part due to the particular relevance of wallet app411 to the subject matter of this disclosure. Furthermore, a separate representation of wallet app411 may also be considered to represent the possibility that it is stored in a secure element (SE-not shown, separate from block 411 or block 408), which may be provided in some embodiments of mobile device 102 to provide enhanced security for wallet app411 and/or sensitive data associated therewith. The SE (if present) may be conventional in its hardware. Additionally or alternatively, the security of wallet app411 may enhance execution through known alternatives of SE, such as TEE (trusted execution environment).

in the sense that the SE includes processing power, it may functionally (although perhaps not physically) overlap with block 406; to the extent that the SE includes storage (particularly program storage) capabilities, it may functionally (although perhaps not physically) overlap with block 408.

The wallet app411 may have one or more digital payment account cards/payment applications (not separately shown) associated therewith and accessible through the wallet app 411.

As is typical for smart phones, the mobile device 102 may include mobile communication functionality as represented by block 412. The mobile communication functions may include voice and data communications over a mobile communication network (not shown) in which the mobile device 102 is registered.

further, to facilitate use as a payment-enabled device, the mobile device 102 may include short-range radio communication capabilities (block 414), including, for example, NFC (near field communication). Thus, block 414 may represent a suitable antenna (not separately shown) suitable for NFC communications and driving and receiving circuitry associated with the antenna. It will be appreciated that the NFC antenna may be separate and distinct from the antenna (not separately shown) used by the mobile device 102 for the mobile communication functions represented by block 412. With the NFC functionality, wallet app, and one or more digital payment account card/payment apps, the mobile device 102 may be functionally presented at the reader device 104/104a to perform a purchase transaction via contactless transaction processing with a point of sale.

From the foregoing discussion, it will be appreciated that the blocks depicted in FIG. 4 as components of mobile device 102 may actually overlap one another and/or that functional connections may exist between the blocks that are not explicitly shown in the figure. It is also contemplated that, as with a typical smartphone, mobile device 102 may include a rechargeable battery (not shown) contained within housing 403 and providing power to the active components of mobile device 102.

Although the mobile device 102 has been primarily described herein as a smartphone, in other embodiments, other types of mobile devices with similar functionality may be used in place of a smartphone.

Fig. 5 is a block diagram of an embodiment of the transaction control server computer 202 shown in fig. 2 as part of the payment system 200.

In some embodiments, the hardware aspects of the transaction control server computer 202 may be comprised of typical server computer and/or mainframe computer hardware, but may be controlled by software so that it functions as described herein.

The transaction control server computer 202 may include a processor 500 operatively coupled to a communication device 501, a storage device 504, an input device 506, and an output device 508. The communication device 501, the storage device 504, the input device 506, and the output device 508 may all be in communication with the processor 500.

The processor 500 may be comprised of one or more processors. The processor 500 is operable to execute processor-executable steps contained in program instructions described below in order to control the transaction control server computer 202 to provide desired functionality.

The communication device 501 may be used to facilitate communications with, for example, other devices, such as one or more components of the payment network 110 a. For example, the communication device 501 may include a number of communication ports (not separately shown) to allow the transaction control server computer 202 to simultaneously engage in data communications regarding a number of payment account transaction requests.

Input device 506 may include one or more of any type of peripheral device commonly used for inputting data into a computer. For example, input devices 506 may include a keyboard and a mouse. Output device 508 may include, for example, a display and/or a printer.

Storage 504 may include any suitable information storage device, including a combination of magnetic storage (e.g., hard disk drives), optical storage (such as CDs and/or DVDs), and/or semiconductor memory devices (such as Random Access Memory (RAM) and Read Only Memory (ROM) devices), as well as so-called flash memory. Any one or more of such information storage devices may be considered a computer-readable storage medium or a computer-usable medium or memory.

The storage device 504 stores one or more programs for controlling the processor 500. The program includes program instructions (which may be referred to as computer readable program code means) embodying processor executable process steps of the transaction control server computer 202 which are executed by the processor 500 to cause the transaction control server computer 202 to function as described herein.

The programs may include one or more conventional operating systems (not shown) that control the processor 500 to manage and coordinate activities and resource sharing in the transaction control server computer 202, and to host applications (described below) running on the transaction control server computer 202.

The programs stored in the storage device 504 may also include a transaction processing application 510. The transaction processing application 510 may control the processor 500 to support the functions of the transaction control server computer 202 to receive and process payment account transaction requests in the following manner.

The storage 504 may also store a database manager 512. The database manager may control the processor 500 to store and retrieve payment account transaction data in the manner described herein.

Additionally, the storage device 504 may store outlier detection model selection software 514. Outlier detection model selection software 514 may control the processor 500 such that the transaction control server computer 202 selects an outlier detection model for each set of account-specific and merchant category-specific data according to the suitability of the type of model to the data in the data set.

Still further, the storage device 504 may store outlier detection software 516. The outlier detection software 516 may control the processor 500 to control the transaction control server computer 202 to detect outlier transactions in payment account transaction requests that refer to the transaction control server computer 202. Details regarding how, in some embodiments, the transaction control server computer 202 may perform outlier detection under the control of the outlier detection software 516 will be provided below.

The storage device 504 may also store other programs, not shown, and the transaction control server computer 202 may also execute other programs. Such other programs may also include, for example, device drivers, communication software, and the like.

In some embodiments, the storage device 504 may also store a database 518 of previous payment account transactions to be analyzed for outlier detection. In addition, the storage device 504 may store other databases (not shown) that may be required for operation of the transaction control server computer 202.

In some embodiments, the transaction control server computer 202 may be associated with the payment network 110a and/or under co-operation with the payment network 110 a. For example, in some embodiments, transaction control server computer 202 may be combined with or at least partially overlap one or more computers that provide the types of functionality available through the "InControl" service provided by Mastercard International, assignee hereof. As will be familiar to those skilled in the art, the "InControl" service provides features such as transaction alerts and voluntary transaction limit settings to holders of Mastercard brand payment card accounts.

In other embodiments, at least some of the functions attributed herein to the transaction control server computer 202 may alternatively be provided by a suitably programmed/modified embodiment of the issuer server computer (represented in fig. 2 by reference numeral 112 a).

fig. 6 is a flow chart illustrating aspects of the present disclosure. In some embodiments, FIG. 6 may represent processing performed at the transaction control server computer 202.

Block 602 in fig. 6 indicates that the subsequent processing blocks represent the processing performed by the transaction control server computer 202 for each account holder and/or each payment system account assigned for oversight/PIN entry management.

At block 604 of fig. 6, the transaction control server computer 202 receives data representing payment account system transactions made by the account holder and/or for the particular account currently being considered. It should be appreciated that this transaction data may be received over time as the transaction progresses, and may include transactions that are authorized and completed (by the account issuer) after a prior submission by the transaction control server computer 202 to perform possible outlier detection.

At block 606 of fig. 6, transaction control server computer 202 sorts the transaction data received at 604 according to the merchant category indicated in the transaction data. (As will be familiar to those skilled in the art, all merchants/recipients of a payment account transaction are assigned to a particular merchant category in the payment system, represented by the merchant category code MCC, which is represented in the data submitted and stored for each proposed payment account system transaction. As is well known to those skilled in the art, a number of merchant categories for payment account system transactions have been established. It may also indicate the date of the transaction.

block 608 in fig. 6 indicates that each subsequent processing block is associated with each merchant category data entry for the current account holder/payment system account. At block 610, transactions classified to the current merchant category data entry may be analyzed. More specifically, a corresponding distribution of transaction amounts may be analyzed. Thus, if at least two transactions are not represented, the analysis of block 610 may be deferred, as indicated by dashed block 612, until sufficient transaction data has been sorted into/stored in the current merchant category data entry.

based on the analysis at block 610, an outlier detection model may be fitted to the distribution of transaction amounts, as represented by block 614. In some cases, a gaussian model may be selected as the best fit model for the transaction amount data distribution. In other cases, a lognormal model may be selected as the most appropriate model to distribute the transaction amount data. In other embodiments and/or in other cases, other kinds of outlier detection models may be applied at block 614. The model fitting at block 614 may be performed according to known principles for fitting a model to a data set.

At block 616, using the model selected at 614, an outlier detection threshold may be set based on predetermined criteria. For example, in the case of a gaussian model, the threshold value may be set to a nominal transaction amount corresponding to a positive one of the sigma points calculated based on a gaussian curve fitted to the data distribution. Alternatively, the outlier detection threshold may be calculated using one and one half sigma point positive or two sigma points positive. Other specific degrees of sigma may be used instead of those just specified.

Where a lognormal model is selected at block 614, the resulting lognormal curve may be transformed into a gaussian curve, the threshold points may be determined according to one of the criteria indicated in the previous paragraph, and then the gaussian curve including the calculated threshold points may be transformed back to the original lognormal curve to indicate the threshold points on the lognormal curve.

FIG. 7 is a histogram of simulated example transaction amount data for transactions in the "fast food" merchant category for transactions made by a particular account holder; fig. 7 shows a diagrammatic representation of the processing at blocks 610, 614 and 616 in fig. 6. In the example of FIG. 7, a Gaussian model is selected as the best fit to the transaction amount distribution. The vertical axis of the histogram indicates the frequency of a particular transaction amount in the data set. The horizontal axis of the histogram indicates the transaction amount (in dollars). A gaussian model curve 700 is shown fitted to the data represented by the histogram bar. In this case, it is assumed that the outlier threshold is calculated as one sigma point positive (reference numeral 702 on the model curve 700). This point on the model curve corresponds to a nominal transaction amount of $ 43.00 indicated at 704. Therefore, based on the analysis of the simulated data set shown in FIG. 7, $ 43.00 was calculated as the outlier detection threshold for transactions in the fast food restaurant business category for this particular account holder.

FIG. 8 is a histogram of simulated transaction amount data for transactions in the "department store" merchant category for transactions made by a particular account holder; fig. 8 shows another illustration of the processing at blocks 610, 614 and 616 in fig. 6. In fig. 8, a lognormal model is selected as the best fit to the transaction amount distribution. The vertical axis of the histogram indicates the frequency of a particular transaction amount in the data set. The horizontal axis of the histogram indicates the transaction amount (in dollars). A lognormal model curve 800 is shown fitted to the data represented by the histogram bar. In this case, assume that the calculated outlier threshold point on the curve falls at 802, corresponding to the nominal transaction amount of $ 88.00 as indicated at 804. Thus, in this case, based on the analysis of the simulated data set shown in fig. 8, $ 88.00 was calculated as the outlier detection threshold for transactions for this particular account holder's department store merchant category. It is assumed that the outlier threshold in this case reflects a predetermined criterion for setting a threshold point on the model curve 800. For example, as described above, the lognormal curve may have been transformed into a gaussian curve to set the threshold point, and then inverse-transformed to apply the threshold point to the lognormal curve.

In some embodiments, for each merchant category (and for each account holder), the outlier threshold analysis and calculation may be updated periodically, or even dynamically each time new transaction data is received in the merchant category in question. In some embodiments, over time (e.g., after a year has elapsed since the date of the transaction), the individual transaction data records may become stale and discarded. The discarding of stale data may also be dynamically reflected by recalculating the outlier detection threshold.

In view of block 608 in fig. 6, the analysis of blocks 610, 614, 616, etc. may be performed for a given account holder with respect to a plurality of different merchant categories, such as three, four, or more merchant categories.

In view of block 602, data collection and outlier threshold setting by category may be performed with respect to a number of different account holders (potentially for a significant number of account holders, i.e., thousands, even hundreds of thousands, or even more).

FIG. 9 is a flow diagram illustrating a process that may be performed in accordance with aspects of the present disclosure. In some embodiments, the process of FIG. 9 may be performed by the transaction control server computer 202.

At block 902 in fig. 9, the transaction control server computer 202 may receive a payment account system request to determine whether PIN entry is required for this transaction. It may be assumed that the transaction in question is initiated at the point of sale as a contactless transaction. It may be the case that the payment network 110a may be operable to detect when a contactless transaction authorisation request message is received in relation to an account for which a variable PIN entry threshold has been implemented, and when so detected, the payment network 110a may forward the request message to the transaction control server computer 202, proceeding to process step 902.

In the process of FIG. 9, decision block 904 may follow block 902. At decision block 904, the transaction control server computer 202 may determine whether an outlier detection threshold has been determined for this particular account and for the merchant category indicated in the transaction request message received at 202 (as in the process of fig. 6). For example, the transaction control server computer 202 may access the database 518 (fig. 5) to determine whether the relevant outlier detection threshold has been stored in the database 518. If so, decision block 906 may follow decision block 904 in the process of FIG. 9.

At decision block 906, the transaction control server computer 202 may determine whether the transaction request received at block 902 is an "outlier". For example, in making this determination, the transaction control server computer 202 may compare the transaction amount indicated in the transaction request to an associated outlier detection threshold. If the transaction amount exceeds the outlier detection threshold, a positive determination may be made at decision block 906. If the transaction amount does not exceed the outlier detection threshold, a negative determination may be made at decision block 906.

If a negative determination is made at decision block 906, block 908 may follow decision block 906 in the process of FIG. 9. At block 908, the transaction control server computer 202 acts such that no PIN entry is required. For example, as part of the processing of block 908, the transaction control server computer 202 may signal to the payment network 110a that no PIN entry is required. The payment network 110a may then route the transaction authorization request message to the issuer 112 without the transaction requiring PIN entry.

If an affirmative determination is made at decision block 906, block 910 may follow decision block 906. At block 910, the transaction control server computer 202 may act in a manner that requires PIN entry for the requested transaction. For example, the transaction control server computer 202 may signal the payment network 110a to indicate that the transaction has been found to be outlier and requires PIN entry. The payment network 110a may then route a message to the point of sale to indicate that the point of sale is to request PIN entry from the account holder/user.

Referring again to decision block 904, it may be the case that a negative determination (i.e., a determination that an associated outlier detection threshold has not been set for this account and this merchant category) has occurred. If a negative determination is made at decision block 904, block 912 may follow decision block 904. At block 912, a conventional decision process as to whether PIN entry is required may prevail. For example, the process may be passed back to the point of sale to apply a standard predetermined threshold to decide whether a PIN needs to be entered. Alternatively, the transaction control server computer 202, the payment network 110a, or the account issuer may apply a standard threshold amount to determine whether the transaction requires PIN entry. In some embodiments, PIN entry may alternatively not be required at all when an outlier detection threshold has not been established for account and merchant category combinations. As another alternative, PIN entry may always be required when an outlier detection threshold has not been established for account and merchant category combinations.

It should be understood that the transaction control server computer 202 may apply the process of fig. 9 to many different account/account holder transaction requests. The process of fig. 9 may be applied to a large number of transactions over a period of time for a given account holder. Again, for a given account holder, the process of fig. 9 may be applied to transactions in a number of different merchant categories (e.g., at least three or more), with results varying from transaction to transaction, from merchant category to merchant category, and with results that may vary over time. There may be differences in merchant categories for which outlier detection thresholds are set for different account holders. In many cases, corresponding individual outlier detection thresholds may be set and applied across several (or a substantial number) of the same merchant categories for a large number of different account holders/accounts. As mentioned above in connection with fig. 6, the outlier detection threshold may be updated over time as new transactions are received or as old transactions become stale and purged from the relevant data entries.

With the processes described in fig. 6 and 9, the decision as to when PIN entry is required for contactless payment account transactions, which is only or to a large extent required for "outlier" transactions, can be made in a manner that reflects the actual spending habits of the user. Thus, the trade-off between convenience and security of contactless payment transactions may be improved by reducing transactions requiring PIN entry without significantly increasing the security risk, relative to conventional practice of using a "one size fit all" threshold amount.

In some embodiments, as is conventional, after a certain number (e.g., four or five) of consecutive transactions that do not require PIN entry, the next transaction (regardless of the transaction amount) may require PIN entry. The counter for this purpose may be maintained, for example, in the payment device, on the account issuer computer, or at another convenient location.

In some embodiments, all transactions stored for outlier detection analysis may be contactless transactions. In other embodiments, other types of transactions are also included. In some embodiments, online transactions are not included in stored transactions for outlier detection analysis.

As used herein and in the appended claims, the term "computer" should be understood to encompass a single computer or two or more computers in communication with each other.

As used herein and in the appended claims, the term "processor" should be understood to encompass a single processor or two or more processors in communication with each other.

As used herein and in the appended claims, the term "memory" should be understood to encompass a single memory or storage device or two or more memory or storage devices.

As used herein and in the appended claims, a "server" includes a computer device or system that responds to a large number of service requests from other devices.

the flowcharts herein and their descriptions should not be understood to prescribe a fixed order in which to perform the method steps described therein. Rather, method steps may be performed in any order that is practicable, including simultaneous performance of steps.

As used herein and in the appended claims, the term "payment card system account" includes a credit card account, a deposit account that an account holder may access using a debit card, a prepaid card account, or any other type of account from which a payment transaction may be completed. The terms "payment card system account" and "payment card account" and "payment account" are used interchangeably herein. The term "payment card account number" includes a number that identifies a payment card system account or a number carried by a payment card, or a number used to route transactions in a payment system that processes debit and/or credit card transactions. The term "payment card" includes credit cards, debit cards, pre-paid cards, or other types of payment instruments, whether physical or virtual.

As used herein and in the appended claims, the term "payment card system" refers to a system for processing purchase transactions and related transactions. One example of such a system is a system operated by Mastercard international corporation, the assignee of the present disclosure. In some embodiments, the term "payment card system" may be limited to systems in which member financial institutions issue payment card accounts to individuals, businesses, and/or other organizations.

although the present disclosure has been described in connection with specific exemplary embodiments, it should be understood that various changes, substitutions, and alterations apparent to those skilled in the art may be made to the disclosed embodiments without departing from the spirit and scope of the present disclosure as set forth in the following claims.