SYSTEM AND METHODS TO PREVENT UNAUTHORIZED USAGE OF CARD READERS

Abstract

A contactless card reader comprises a contactless card reader front-end coupled to a processor. A communications module is coupled to the processor and a set of sensors is coupled to the processor. The set of sensors determines parameters related to the location, orientation and motion of the card reader. The processor receives the parameters from the set of sensors and utilizes the parameters and scenario configuration data to evaluate a rule. The result of the evaluation of the rule results in a limitation on the operation of the card reader. The communications module is configured to intermittently receive the scenario configuration data from external sources.

Description

TECHNICAL FIELD

The present disclosure relates to the secure use of contactless card readers. In particular, it relates to the use of determining when a card reader is used in a fraudulent manner.

BACKGROUND

There exists a number of short-range wireless technologies to communicate between electronic devices such as smart tags and payment cards. Example of this type of wireless technology include touchless protocols such as RFID and NFC (Near Field Communication). There are a number of common applications known in the art such as bank cards, stored value cards, loyalty cards, and access cards. These cards often contain valuable and sensitive data which needs to be protected from unauthorized access. It is important to protect the privacy of the data and to ensure its authenticity and integrity.

Though there are obvious advantages of using a touchless card to make payments there are drawbacks as well. Inherent in the wireless nature of the technology is that it is much easier to access the card or to eavesdrop on data being transferred between a card and a card reader when compared to other technology that requires a direct connection between the card and the reader. Due to the fact that a card reader can read the card data without touching the card, unauthorized accessing or eavesdropping of card data transfers may occur without the user being aware of the unauthorized card reading operation.

A number of solutions to this problem that have been proposed. Some are based on improving security in the card while others concentrate on improving security in the card reader. A card reader can require the manual input of an authorization code or password at power up or at a predefined interval. Other systems detect when a card has been removed from the proximity of a reader and automatically stop any data transfer operations. Other security measures require the card holder to authenticate using an emulated card or e-wallet application on a mobile device that asks for a user password or biometric authentication before allowing access. These existing solutions are all cumbersome and detract from the simplicity of using touchless card technology. Furthermore, most existing solutions focus on increasing the reader side security. There exists a need for technology that supplements and complements security features in the card, emulated card, or wallet by increasing security in the card reader. Solutions should decrease the risk of data theft while preserving the ease-of-use of the NFC and other touchless card and wireless technology.

SUMMARY

In one exemplary embodiment of the invention a card reader comprises a contactless card reader front-end coupled to a processor. A communications module is coupled to the processor and a set of sensors is coupled to the processor. The set of sensors determines parameters related to the location, orientation and motion of the card reader. The processor receives the parameters from the set of sensors and utilizes the parameters and scenario configuration data to evaluate a rule. The result of the evaluation of the rule results in a limitation on the operation of the card reader.

In some embodiments of the invention the communications module is configured to intermittently receive the scenario configuration data from external sources. The communications module may be configured to tether an external device to the card reader. The external device comprises a second set of sensors. The second set of sensors determines parameters related to the location, orientation and motion of the card reader. The processor receives the second set of parameters through the communications module.

The card reader may be installed in a location and the rule may comprise parameters related to the location and movement of the location. The card reader may be fixed to a location. The card reader may be mobile within a location. The card reader may be a handheld device.

Another exemplary embodiment of the comprises a method of operating a card reader in a location. The method comprises installing the card reader in the location. The installation comprises classifying a mobility of the location and classifying a portability of the card reader. The card reader is configured with a scenario associated with the mobility of the location and the portability of the card reader. Parameters are read from a set of sensors located within the card reader. The parameters are related to the location, orientation and motion of the card reader. The parameters are evaluated to evaluate a rule. The rule is based on the scenario. The result of the evaluation of the rule results in a limitation on the operation of the card reader.

In some embodiments of the invention the configuration of the card reader comprises accessing the card reader through a communications module integrated with the card reader.

In other embodiments of the invention the method further comprises tethering an external device to the card reader. The external device comprises a second set of sensors. The second set of sensors determines parameters related to the location, orientation and motion of the card reader. The card reader receives the second set of parameters through the communications module. The card reader is installed in a location and the rule comprises parameters related to the location and movement of the location.

The method may apply when the card reader is fixed to a location. The method may apply when the card reader is mobile within a location. The method may apply when the card reader is a handheld device.

The foregoing and additional aspects and embodiments of the present disclosure will be apparent to those of ordinary skill in the art in view of the detailed description of various embodiments and/or aspects, which is made with reference to the drawings, herein.

BRIEF DESCRIPTION OF THE DRAWINGS

For a more complete understanding, reference is now made to the following description taken in conjunction with the accompanying Drawings in which:

FIG. 1 is a diagram of a card reader with a non-persistent connection to a backend host;

FIG. 2 is a diagram of a card reader tethered to another device;

FIG. 3 is a table illustrating examples for various locations and mobility options of a card reader;

FIG. 4A and FIG. 4B illustrate rules for given combinations of reader motion and installation motion for a large set of sensors; and

FIG. 5 illustrates rules for given combinations of reader motion and installation motion for a limited set of sensors.

While the present disclosure is susceptible to various modifications and alternative forms, specific embodiments or implementations have been shown by way of example in the drawings and will be described in detail herein. It should be understood, however, that the disclosure is not intended to be limited to the particular forms disclosed. Rather, the disclosure is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of an invention as defined by the appended claims.

DETAILED DESCRIPTION

An example contactless card reader, using hardware and software compatible with the NFC or RFIC standards, is shown in FIG. 1. The card reader 101 comprises a number of electronic components such as a processor 104, an NFC reader front-end 103, a communication module 102, and a number of sensors 105. The processor 104 includes a CPU, volatile memory, and non-volatile memory as is known in the art. Non-volatile memory stores software or firmware to operate the device and may also store parameters, settings, and data tables to be preserved across power cycles. Examples of non-volatile memory include semiconductor ROM chips, flash memory cards, solid-state disks, and hard disks. Volatile memory is used to store program code for execution and variables used during program execution. The most common example of volatile memory is semiconductor RAM.

The NFC reader front-end 103 contains the analog and digital wireless circuitry to implement the NFC wireless protocol and to connect and communicate with the processor. The NFC reader front-end 103 can also be any other type of wireless, short-range wireless standard including RFID and Bluetooth. In some applications, the NFC reader front-end 103 can be configured by the processor 104.

The communications module 102 interfaces with a backend host 107 using any number of wired or wireless protocols. Wired protocols include Ethernet, USB, and serial ports. Wireless protocols include 802.11 and cellular phone technologies such as 3G or LTE. The backend host 107 can be used to monitor and configure the reader 101 and can be a computer, laptop, or other suitable device. The card reader 101 as per an exemplary embodiment of the invention includes a number of sensors 105 that may include a GPS, beacon receivers, altimeters, orientation or incline sensors, a compass, accelerometer and gyroscopes. A beacon signal is any signal that the card reader can identify and help the card reader to know it is near a particular spot. Examples of beacons are a dedicated transmitter that transmits a special data packet, a Wi-Fi router with a particular MAC address, and a cellular base station. Though the beacon is typically placed in a location, the card reader requires a receiver to detect the signal emitted by the beacon. Accelerometers may read 2 or 3 axis of motion and can therefore also function to indicate the orientation and incline of the card reader.

Sensors 105 can be used to detect the location and orientation of the card reader 101 as well as the speed, direction, and acceleration of movement of the card reader 101. The processor 104 interfaces with sensors 105 in order to monitor and collect readings. Sensor readings are analyzed to evaluate the likelihood of unintended, out of bounds, or fraudulent usage of the card reader.

Finally, the reader 101 will include any necessary antennas and front-end system 103 for reading cards by a variety of means including swiping, tapping, or inserting the card in a slot.

Again referring to FIG. 1, the communication module 102, backend host 107, and wired or wireless channel 106 is shown in a dashed line. This is to reflect the fact that these elements of the card reader 101 and card reader system may be on-line or off-line.

Configuration and transaction records may be loaded or unloaded in real time or in batches. Either the card reader 101 or the backend host 107 can determine when the communications elements go on-line or off-line. In on-line systems, analysis and decision making may be done by the backend host 107 or the card reader 101. In off-line systems, the card reader 101 will perform any required analysis, rule evaluation, and decision making.

FIG. 2 shows another embodiment of the invention where the card reader 101 can be connected to another device 108 to make use of capabilities of the other device 108. The other device 108 may be a handheld, mobile device such as a mobile handset. In this configuration the card reader 101 can make use of sensors 111 in the other device 108. The card reader 101 may also make use of the processing power 110 of the other device. If the other device 108 is not secure, the reader 101 will only make use of the other device's sensors 111 in ways that do not compromise analyses used to make security related decisions. For example, a GPS location sensor and an altimeter can be used if wired connection or short-range wireless connection is made, because the two devices' locations are expected to be quite close, however, an accelerometer and gyroscope are unlikely to be used unless it is some way to make sure there is no relative movement between the two devices. Either the backend host 107 of FIG. 1 or the other device 108 of FIG. 2 can be used to augment or replace the processing power of the card reader 101 for analysis of data and results, or decision making.

In use, the card reader 101 is first installed in its location and then authenticated with itself or over a network. Installation can be done through a user interface on the card reader 101, through an attached device 108, or through the backend host 107 accessed over the network 106. During the installation the card reader 101 is configured with information concerning its location, orientation, expected motion characteristics, and other parameters. Location information may include known GPS coordinates, altitude, and data concerning a nearby beacon. Orientation may include the direction the card reader 101 is facing and the inclination of the card reader. Motion may include whether the card reader 101 is expected to move, or if it does move, how fast and far it is expected to move. Similar configuration may also be done with respect to the location of the card reader 101. For example, a fixed store is not expected to move, a train may move at a moderate pace, while an aircraft will accelerate quickly and move much more quickly. A range of acceptable values may also be programed for sensor readings. For example, an installation in a train may not be expected to have a velocity over 150 km/h. A card reader 101 in a store may not be expected to be further than 20 m from a beacon. A card reader fixed in place may not be expected to have a difference in inclination more than plus or minus 5 degrees.

Authentication may include verifying the identity of the user, merchant, or location. Authentication may also include logging into a network, attaching a dongle, USB device, or external device, and authenticating with a payment processor. Authentication and re-configuration may be repeated under a variety of conditions, examples of which are given below.

A number of scenarios of the real world usage according to embodiments of the invention are shown in FIG. 3. A card reader 101 is classified by “mobility”, that is whether the location it is used in is in motion or is static relative to the earth. For a card reader “static” means the reader location is not in motion relative to earth during card reading, whereas “motion” means the reader location is expected to be in motion relative to earth during card reading. Examples of a card reader location that is static is in a fixed location such as a store. Non-exhaustive examples of a card reader locations that are in motion are if the reader is being used inside a bus, a train, a plane, a cart, or a ship.

Card readers 101 are also be classified by “portability”, that is how they move, are repositioned, held, and are used within their place of use. The term “fixed” means the reader is fixed after installation and authentication and does not move within its location. An example would be if it is bolted to a mount, fixed in a holder, or secured to a counter. “mobile” means the reader location can change after installation and authentication. An example of this is a card reader that is being used in mobile arrangement such being placed on desk or in a cradle which relocates frequently. “Handheld” means the reader is expected to be handheld during card reading, either held by merchant or by the card owner.

A key aspect of the embodiments of the invention is for the card reader 101 to decide whether it is being use as intended. If it is detected that the card reader is not being used as intended this may be considered a security breach and measures can be taken to disable the card reader, limit its use, or require reverification. A number of intended usage scenarios are defined and sets of decision rules are applied to determine if the card reader is being used in the intended environment and in a way that is consistent with the expected behavior of the users. Rules are evaluated using input read from a number of sensors that may be located in the card reader, another device tethered or connected to the card reader, in the location, or in the card itself. In some cases, a single rule may suffice. In others, there may be multiple rules that may vary depending on the type of card, the interface between the card and the card reader 101 and the amount of the transaction, currency of the transaction, the bank or organization that issued the card and a number of other parameters. There may be separate rules for a government issued card, a card issued by a financial institution, a loyalty card, and a card issued by a private business.

FIGS. 4A and 4B gives example of an implementation according to one embodiment of the invention that utilizes a number of sensors; a GPS, beacon, altimeter, orientation/inclination sensor, compass accelerometer, and a gyroscope. Scenarios are defined based on whether the card reader is installed in a location in motion or static and if the reader itself is fixed in place, mobile, or handheld. FIGS. 4A and 4B list the expected data the card reader 101 would read from sensors 105 in the card reader, attached device 111, or other sensors. For each scenario rules are defined based on the location, orientation, and other parameters as sensed by the card reader 101. Location refers to the location of the card reader and can be measured by a GPS, beacons, altimeters, and other sensors. Orientation refers to the directional heading (north, south, east, west) and inclination, whether the reader is level. Orientation can be measured using sensors such as a compass, orientation/incline sensor, and others. Motion refers to the displacement, velocity and acceleration of the card reader over time. Motion can be measured using sensors such as an accelerometer, a gyroscope, and others. Note that for other scenarios and for other sensors, the rules may be modified or additional rules may be added or deleted.

A variance in any of the expected readings triggers an event that may force the card reader to re-authenticate, to shutdown, or to send an alert to a user, administrator, or other party monitoring the system. Variances may be indicated on the card reader, an attached device, or through a monitoring device or party over the network.

One scenario 401 is when the card reader is fixed in a static location. In this case the GPS and altimeter would be expected to correspond to the known location and the signal from a beacon installed in the same location would be received. The orientation and incline would be very close to the readings in which the card reader was installed. The accelerometer and gyroscope would indicate no movement.

Another scenario 402 is when the card reader is fixed in a location that is in motion. An example of this may be a card reader fixed at a check-out counter in a store on a train. The GPS and altimeter reading should be within the expected range and a beacon placed within the location will be readable. The orientation sensor/incline sensor will return a range of values that are consistent and cross-referenced with the present location of the installation as measured by the location readings and the motion readings. The compass readings will be consistent with the gyroscope readings. As the installation is expected to move, motion readings outside an expected range will be deemed to be unusual and may trigger a re-authorization procedure. Accelerometer readings should agree with the GPS data and orientation data. The gyroscope should return data consistent with the compass readings.

A further scenario 403 is where the card reader is mobile and the installation is static. This may occur when there is a mobile cart within a large building. The cart moves within the location but is not expected to exit the building. The location sensors, the GPS and altimeter will be within the range consistent with the bounds of the location. The location information will remain stable for a predefined time before a card is read since the cart will have to stop moving in order to process a transaction. Beacon information will be readable. Similarly, the orientation information will be within bounds and be stable for a short time before the card is read. Accelerometer and gyroscope information will be static within tight bounds. If no movement occurs for a predefined period of time (the cart has not moved in a long time), re-authorization may be required.

The next scenario 404 is a mobile reader installed on a platform in motion. This could be the case of a card reader fixed to a food and drink cart used on an aircraft. The GPS and altimeter sensor data will be consistent with an aircraft flight or more specifically, with the flight plan of a particular aircraft. GPS information will indicate that the cart and reader are still on the aircraft. Location will be used to supplement the orientation information. The orientation/incline sensor will be within a limited range qualified by the rate of change of the motion and location information. The compass data will agree with the gyroscope data. Motion data is used to supplement the orientation information for decision making. The accelerometer readings will agree with the GPS data and orientation data. The gyroscope will agree with the compass.

Next the scenario 405 of a handheld card reader in a static location is considered. This would correspond with a handheld payment card reader in a restaurant. The GPS and altimeter would be a match for the bounds of the location. A signal from a beacon would be received. A location change that exceeded the location bounds would trigger a re-authorization as it could indicate that the card reader had left the building. Due to the large number of movements experienced by a handheld device orientation information would not be used. Acceptable ranged of acceleration and velocity would be permitted as expected for a handheld device where the holder would be expected to be walking.

The final scenario 406 depicted in FIG. 4B is the case of a handheld card reader when the installed location is in motion. The location will be verified against the route of the location, such as in a delivery truck, where the route may also change based on season or weather. The GPS and altimeter data will be consistent with the route and a signal from a beacon in the truck will be received. Often orientation and motion information will not be used in this scenario.

FIG. 5 shows an alternative preferred embodiment of a card reader 101 with fewer sensors 105, 111 compared to the previous embodiment of FIGS. 4A and 4B. The embodiment of FIG. 5 cover the same scenarios as in FIGS. 4A and 4B but the sensors 105, 111 are limited to a beacon, orientation/inclination sensor, and an accelerometer. Sensors and readings are still divided into three groups; location, orientation, and motion. A beacon is installed at the location and is used to verify that the card reader is within range of the location. If the card reader moves too far from the beacon it will lose contact with the card reader 101. The orientation of the card reader is detected using only an orientation/incline sensor. An accelerometer is used to determine motion.

Processing may be done by the card reader 101, other tethered device 108, the backend host 107, or any combination of the above.

The above listed preferred implementation by no means to be exhaustive, and many possible ways of implementation using different combinations of sensors are possible.

Although the algorithms described above including those with reference to the foregoing flow charts have been described separately, it should be understood that any two or more of the algorithms disclosed herein can be combined in any combination. Any of the methods, algorithms, implementations, or procedures described herein can include machine-readable instructions for execution by: (a) a processor, (b) a controller, and/or (c) any other suitable processing device. Any algorithm, software, or method disclosed herein can be embodied in software stored on a non-transitory tangible medium such as, for example, a flash memory, a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), or other memory devices, but persons of ordinary skill in the art will readily appreciate that the entire algorithm and/or parts thereof could alternatively be executed by a device other than a controller and/or embodied in firmware or dedicated hardware in a well-known manner (e.g., it may be implemented by an application specific integrated circuit (ASIC), a programmable logic device (PLD), a field programmable logic device (FPLD), discrete logic, etc.). Also, some or all of the machine-readable instructions represented in any flowchart depicted herein can be implemented manually as opposed to automatically by a controller, processor, or similar computing device or machine. Further, although specific algorithms are described with reference to flowcharts depicted herein, persons of ordinary skill in the art will readily appreciate that many other methods of implementing the example machine readable instructions may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.

It should be noted that the algorithms illustrated and discussed herein as having various modules which perform particular functions and interact with one another. It should be understood that these modules are merely segregated based on their function for the sake of description and represent computer hardware and/or executable software code which is stored on a computer-readable medium for execution on appropriate computing hardware. The various functions of the different modules and units can be combined or segregated as hardware and/or software stored on a non-transitory computer-readable medium as above as modules in any manner, and can be used separately or in combination.

While particular implementations and applications of the present disclosure have been illustrated and described, it is to be understood that the present disclosure is not limited to the precise construction and compositions disclosed herein and that various modifications, changes, and variations can be apparent from the foregoing descriptions without departing from the spirit and scope of an invention as defined in the appended claims.

Claims

1. A method of managing security of a card reader, comprising: receiving, by a processor coupled with one or more sensors of a card reader, sensor data indicative of parameters related to one or more of a location, an orientation, and a motion of the card reader;evaluating, by the processor, one or more rules based at least in part on the sensor data to detect when the sensor data fails to satisfy at least one of the one or more of the rules;triggering, by the processor, an event of the card reader when the sensor data is detected to fail to satisfy at least one rule; andin response to detecting the event, causing the card reader to initiate an action associated with the event.

2. The method of claim 1, wherein the card reader is successfully authenticated before receiving the sensor data, and initiating the action associated with the event comprises: forcing, by the processor, the card reader to perform a re-authentication process to verify one or more of an identity of a user of the card reader, an identity of a merchant associated with the card reader, and a location of the card reader.

3. The method of claim 1, wherein each of the one or more rules defines at least (i) an expected motion type associated with the card reader, and (ii) an expected motion type associated with a location at which the card reader is located, wherein the expected motion type associated with the card reader comprises fixed or mobile, and the expected motion type associated with the location at which the card reader is located comprises fixed or mobile, and evaluating the one or more rules based on at least the sensor data comprises: determining whether the received sensor data is indicative of a contrary type of motion of the card reader to: the expected motion type associated with the card reader and/or the expected motion type associated with the location at which the card reader is located; andwhen the contrary type of motion is determined from the sensor data, detecting that the sensor data fails to satisfy at least one of the one or more of the rules.

4. The method of claim 3, wherein the one or more sensors comprise a first sensor and a second sensor that each detect a same type of motion, and wherein the contrary type of motion is detected when first motion data generated by the first sensor and second motion data generated by the second senor are inconsistent types of motion.

5. The method of claim 1, wherein the card reader is successfully authenticated before receiving the sensor data, and initiating the action comprises: disabling, by the processor, operation of the card reader.

6. The method of claim 1, wherein the card reader is successfully authenticated before receiving the sensor data, and initiating the action comprises: generating, by the processor, an alert message; andtransmitting, by the processor, the alert message to a user that monitors the card reader.

7. The method of claim 1, wherein the event of the card reader triggered when the sensor data is detected to fail to satisfy the at least one rule comprises one or more of: a card reader reauthentication event, a card reader shutdown event, a card reader disabling event, a card reader usage limitation event, and an alerting event.

8. The method of claim 1, wherein the one or more sensors comprise one or more of a positioning sensor, an altimeter sensor, a compass sensor, a gyroscope, and a beacon receiver.

9. The method of claim 1, wherein the one or more sensors are comprised in the card reader.

10. The method of claim 1, wherein the one or more sensors are comprised in a device to which the card reader is coupled.

11. A card reader comprising: one or more sensors configured to generate sensor data;a processor, coupled with the one or more sensors, configured to: receive, from the one or more sensors, sensor data indicative of parameters related to one or more of a location, an orientation, and a motion of the card reader,evaluate one or more rules based at least in part on the sensor data to detect when the sensor data fails to satisfy at least one of the one or more of the rules,trigger an event of the card reader when the sensor data is detected to fail to satisfy at least one rule, andin response to detection of the event, cause the card reader to initiate an action associated with the event.

12. The card reader of claim 11, wherein the card reader is successfully authenticated before the processor receives the sensor data, and the processor configured to initiate the action associated with the event comprises the processor further configured to: force the card reader to perform a re-authentication process to verify one or more of an identity of a user of the card reader, an identity of a merchant associated with the card reader, and a location of the card reader.

13. The card reader of claim 11, wherein each of the one or more rules defines at least (i) an expected motion type associated with the card reader, and (ii) an expected motion type associated with a location at which the card reader is located, wherein the expected motion type associated with the card reader comprises fixed or mobile, and the expected motion type associated with the location at which the card reader is located comprises fixed or mobile, and evaluating the one or more rules based on at least the sensor data comprises: determining whether the received sensor data is indicative of a contrary type of motion of the card reader to: the expected motion type associated with the card reader and/or the expected motion type associated with the location at which the card reader is located; andwhen the contrary type of motion is determined from the sensor data, detecting that the sensor data fails to satisfy at least one of the one or more of the rules.

14. The card reader of claim 13, wherein the one or more sensors comprise a first sensor and a second sensor that each detect a same type of motion, and wherein the contrary type of motion is detected when first motion data generated by the first sensor and second motion data generated by the second senor are inconsistent types of motion.

15. The card reader of claim 11, wherein the card reader is successfully authenticated before the processor receives the sensor data, and the processor configured to initiate the action comprises the processor further configured to: disable operation of the card reader.

16. The card reader of claim 11, wherein the card reader is successfully authenticated before the processor receives the sensor data, and the processor configured to initiate the action comprises the processor configured to: generate an alert message; andtransmit the alert message to a user that monitors the card reader.

17. The card reader of claim 11, wherein the event of the card reader triggered when the sensor data is detected to fail to satisfy the at least one rule comprises one or more of: a card reader reauthentication event, a card reader shutdown event, a card reader disabling event, a card reader usage limitation event, and an alerting event.

18. A non-transitory machine-readable storage medium having instructions stored thereon which when executed by a processor of a card reader, cause the card reader to perform operations for managing security of the card reader, the operations comprising: receiving, from one or more sensors of the card reader, sensor data indicative of parameters related to one or more of a location, an orientation, and a motion of the card reader;evaluating one or more rules based at least in part on the sensor data to detect when the sensor data fails to satisfy at least one of the one or more of the rules;triggering an event of the card reader when the sensor data is detected to fail to satisfy at least one rule; andin response to detecting the event, causing the card reader to initiate an action associated with the event.

19. The non-transitory machine-readable storage medium of claim 18, wherein the card reader is successfully authenticated before receiving the sensor data, and initiating the action associated with the event comprises: forcing the card reader to perform a re-authentication process to verify one or more of an identity of a user of the card reader, an identity of a merchant associated with the card reader, and a location of the card reader.

20. The non-transitory machine-readable storage medium of claim 18, wherein each of the one or more rules defines at least (i) an expected motion type associated with the card reader, and (ii) an expected motion type associated with a location at which the card reader is located, wherein the expected motion type associated with the card reader comprises fixed or mobile, and the expected motion type associated with the location at which the card reader is located comprises fixed or mobile, and evaluating the one or more rules based on at least the sensor data comprises: determining whether the received sensor data is indicative of a contrary type of motion of the card reader to: the expected motion type associated with the card reader and/or the expected motion type associated with the location at which the card reader is located; andwhen the contrary type of motion is determined from the sensor data, detecting that the sensor data fails to satisfy at least one of the one or more of the rules.