IT202100008891A1 - METHOD AND SYSTEM FOR VERIFYING TRANSACTIONS - Google Patents

Description

?METHOD AND SYSTEM FOR VERIFYING TRANSACTIONS?

DESCRIPTION

Technical field

The present invention relates to transaction verification and, in particular, but not exclusively, to a method of processing data in a user device for generating user verification data for use in a transaction verification system, and to a system for verifying a transaction after that ? the transaction took place.

Context

Many transactions made by a user using a user device may require verification. For example, a transaction can involve the use of application software on a user device, such as a mobile phone or computer, to verify identity? of a user. Typically, a transaction on a user device is verified before the transaction is completed. For example, can facial recognition and/or fingerprint recognition be used to verify identity? of a user and, if the verification is not successful, the transaction pu? be rejected. However, in the event of a disputed transaction, it may be useful to perform a further check after that ? the transaction took place.

Summary

According to a first aspect of the invention, ? provided a method for processing data in a user device to generate user verification data for use in a transaction verification system, comprising the steps of:

derive first user behavior data from a first plurality? of sets of data, each of which ? generated by a plurality? of different elements of the user device, and each of which ? representative of a user interacting with the user device;

identifying at least a first time interval relating to a transaction involving a user of the user device;

derive second user behavior data from a second plurality? of sets of data, each of which ? generated by the plurality? of different elements of the device, and each of which ? representative of a user interacting with the user device during at least the first time interval; And

transmitting user verification data, including first user behavior data and second user behavior data, from the device to a transaction verification system.

There? allows the verification system to process the first user behavior data and the second behavior data, for example, for the analysis of a disputed transaction, to determine a probability? that the disputed transaction involved the interaction of a given user with the device. ? clear that the aforementioned method of data processing ? a computer-implemented method.

In an example, the first time interval ? a period of time during which the transaction takes place.

There? allows the second user behavior data to relate to the behavior of the user in the execution of the transaction.

In one example, the method includes the steps of:

identifying a second time slot as a time slot before which the transaction occurs; and/or

identify a third time interval as a time interval after which the transaction takes place,

in which the second plurality? of data sets ? each representative of a user interacting with the device during the first time slot and the second and/or third time slot.

There? allows second user behavior data to relate to user behavior in a period before the and/or after the execution of the transaction.

In one example, the method comprises collecting the second user behavior data in response to receiving an indication that ? a transaction is in progress.

There? allows you to collect data that is appropriate for the time of the transaction.

In one example, the method includes the steps of:

store user behavior data in a storage system on the user device;

receiving timing data indicative of the first time interval from the transaction verification system; And

retrieving the second user behavior data from the storage system on the basis of the timing data.

This allows you to identify and retrieve data relating to a disputed transaction for use in processing through the transaction verification system.

In one example, the derivation of the first and second user behavior data comprises the use of a hardware abstraction functional module configured to transform data generated from the plurality of user behavior data. of different elements of the user device into transformed element data having a normalized format for the verification system.

Generating transformed element data having a normalized format for the verification system allows the verification system to process data independent of the characteristics of a specific user device.

In one example, the derivation of the first and second user behavior data comprises the use of a data processing functional module configured to perform summarization, aggregation, and combination functions on the transformed item data to generate processed item data.

There? allows you to transform raw collected data into processed data, typically summarized, for use in a functional user behavior module.

In one example, the derivation of the first user behavior data comprises the use of a user behavior functional module configured to extract information about a typical user behavior from processed element data related to the first plurality of user behavior data. of data sets.

There? allows the extraction of information from the processed data about the way in which the user typically uses the device used to carry out transactions.

In one example, the derivation of the second user behavior data comprises the use of a user behavior functional module configured to extract information about a user's behavior from processed element data related to the second plurality of user behavior data. of data sets.

There? allows you to extract user behavior information relating to a certain period of time, typically before, during and after that ? made a transaction.

In one example, the plurality of several elements of the user device comprises a sensor.

There? allows you to derive data that is representative of a user interaction involving sensors. The sensors can be, for example, one or more? of the following: a camera; a microphone; an inertial sensor; a temperature sensor; a fingerprint sensor; a keyboard; a touchpad; and a mouse.

In one example, the plurality of various elements of the user device comprises a radio interface of the device.

There? allows you to derive data that are representative of a? user interaction involving one or more? radio interfaces. The radio interfaces can be, for example, one or more? of the following: a WiFi interface; a positioning systems interface, for example, a GPS/GNSS interface; a cellular wireless interface; a Bluetooth interface; and a wireless communication interface, for example, an NFC interface.

In one example, the plurality of different elements of the user device includes one or more? elements selected from: a screen interface; a touch screen interface; an operating system; a speaker or headphone interface; and a timer. The interface can also be a wired interface, such as a USB interface. In each case, there? allows you to derive data that are representative of a? user interaction involving one or more? of the elements.

In one example, the method comprises receiving data indicating data processing rules from the transaction verification system to derive the first user behavior data from the first plurality? of data sets and derive the second user behavior data from the second plurality? of data sets.

There? allows the transaction verification system to generate data processing rules and send them to the user device. There? allows you to develop the processing rules over time, for example, using artificial intelligence techniques through the transaction verification system.

According to a second aspect of the invention, ? provided a system for verifying a transaction after that ? completed the transaction including a user device and the transaction verification system. Typically, the transaction verification system ? configured to process the first user behavior data and the second user behavior data to provide verification of a given transaction.

In one example, the transaction verification system comprises a customer and end user profile form configured to store first and second user behavior data.

There? can? enabling the transaction verification system to verify a transaction in the absence of an electrical connection to the user device.

In one example, the transaction verification system includes a transaction validation module configured to provide an estimate of the probability that a given transaction involved a given user by processing the first and second user behavior data.

There? can? allow the transaction verification system to confirm, or not confirm, with some degree of certainty that a disputed transaction was indeed a case of fraudulent authentication.

In one example, the transaction verification system comprises a data processing module configured to determine data processing rules to be applied by the user device, and to send data indicating the data processing rules to the user device.

There? allows the determination of data processing rules, which typically requires a capacity? of data processing, to be carried out in a processor outside the user device, and furthermore the rules can be developed, for example, using artificial intelligence techniques and/or algorithms, based on data from more than one user? of a device.

Further characteristics and advantages of the invention will become evident starting from the following description of examples of the invention, which ? made with reference to the attached drawings.

Brief description of the drawings

so that the present invention can be understood more? easily, the examples of the invention will now be described, with reference to the attached drawings, in which:

Figure 1 ? a schematic diagram showing a plurality? of user devices communicating with a transaction verification system;

Figure 2 ? a schematic diagram showing a user device configured to process data for generating user verification data for use in a transaction verification system;

Figure 3 ? a flowchart showing a method for processing data in a user device for generating user verification data for use in a transaction verification system;

Figure 4 ? a schematic diagram showing a transaction verification system;

Figure 5 ? a collaboration diagram showing the activation of a new user;

Figure 6 ? a collaboration diagram showing the performance of additional user initialization functions;

Figure 7 ? a collaboration diagram regarding a disputed transaction;

Figure 8 ? a block diagram showing a backend system layout that ? dedicated to a customer; And

Figure 9 ? a block diagram showing a backend system layout that ? shared among multiple customers.

Detailed description

Examples of the invention are described in the context of a system for verifying a transaction after it ? the transaction took place.

As shown in Figure 1, the system comprises one or more? user devices configured to generate user verification data 1a, 1b, 1c such as, for example, a mobile phone, a smartphone, a smartwatch or a computer (such as a tablet pc, or a laptop or a desktop pc), and a system of transaction verification 2, which ? typically implemented by processing data outside the user device, which can? be called data processing ?backend?. Backend processing can be implemented in a data processor in a central office, or pu? be implemented through distributed computing or in the cloud. The one or more? user devices 1a, 1b and 1c are shown in communication with the transaction verification system 2 via a data network 3. The data network can? include a cellular wireless network and other data connections.

Figure 2 ? a schematic diagram showing a user device 1 configured to process data for generating user verification data for use in a transaction verification system. As shown in Figure 2 , the user device has multiple different elements 4 which are used to generate a plurality of elements. of datasets from which first user behavior data are derived. Each set of data ? representative of a user interacting with the user device.

The elements can be, for example, sensors of the user device, such as one or more between a camera, microphone, inertial sensor, temperature sensor, fingerprint sensor, keyboard, touchpad, and mouse. One or more? items may include a device?s radio interface, such as a WiFi interface, a positioning system interface, such as a GPS/GNSS interface, a Bluetooth interface, a cellular?s wireless interface, and a contactless interface, such as an NFC interface. Items may include a wired interface, such as a USB interface. Elements may also include a screen interface, a touch screen interface, a speaker or headphone interface, an operating system, and a timer. In each case, there? allows you to derive data that are representative of a? user interaction involving one or more? of the elements.

User device 1 ? configured to derive first user behavior data from a first plurality? of sets of data, each of which ? generated by at least some of the plurality? of different elements 4 of the user device. The user device ? also configured to identify at least a first time slot relating to a transaction involving a user of the user device, and to derive second user behavior data from a second plurality of sets of data, each of which ? generated by the plurality? of different elements of the device, and each of which ? representative of a user interacting with the user device during at least the first time interval.

As shown in Figure 2 , the user device comprises a hardware abstraction functional module 5, a data processing module 6, a user behavior module 10 and a transaction behavior module 11. The hardware abstraction functional module 5, the data processing module 6 and the user behavior module 10 are used to derive the first user behavior data, and the hardware abstraction functional module 5, the data processing module 6 and the transaction behavior module 11 are used to derive the second user behavior data.

The hardware abstraction functional module 5 ? used to derive the first and second user behavior data by transforming data generated by plurality? of different elements 4 of the user device into transformed element data having a normalized format for the verification system. There? allows the verification system to process data independently of the characteristics of a specific user device. The data processing functional module 6 has summarizing 7, aggregating 8 and combining 9 functional blocks. These operate on the transformed item data to generate processed item data. There? allows you to transform raw collected data into processed data, typically summarized, for use in a functional user behavior module.

The hardware abstraction module 5 transforms data from user device elements into a common normalized format which is compatible with user devices allowed to perform transaction verification. For example, different user devices may have different camera resolution specifications, and the hardware abstraction module takes care of transforming data from the camera to provide data that is compatible, regardless of the specific user device, with the other functional modules it needs to collect. , process and store data.

The data processing module 6, based on data received from the hardware abstraction module 5, transforms the collected raw data into multiple levels of processed data. Its data processing functions can be divided into three main classes: summary; aggregation; and combination. These functions can be performed by means of programmed calculation algorithms, as well as? through artificial intelligence functions and/or algorithms. This module also acts as a counterpart, on the user device side, of the corresponding module 17 present on the backend side, i.e. the verification system 2.

The data processing module 6 pu? be referred to as the data processing and artificial intelligence module.

The user behavior module 10, on the basis of data supplied by the data processing module 6, extracts information about the way in which the user typically uses the device used to carry out the transactions. The information, transmitted in the first user behavior data, can relate to a device identifier, how much and when it is used during the day and during the week. Information may also refer to behavior related to keystrokes or scrolling, for example, using one or two hands to enter data. The information may also refer to applications used more? frequently or, for example, locations where the user device is used.

The transaction behavior module 11, based on data provided by the data processing module 6, extracts detailed user behavior information for a certain period of time before, during and/or after ? made a transaction. The purpose ? similar to user behavior form 10, however ? specifically focused on how you use your device during device-related transactions. The transaction behavior module 11 provides the second user behavior data.

A transaction registration form can record data associated with a transaction, such as screen captures, keystrokes, video, sound and fingerprint authentication, for example, to document the transaction in detail. Registration can be activated at different levels of detail, for example, raw data or data processed by the data processing module 6 according to technical constraints, as well as? regulations, for example, privacy.

A data storage and protection module 13 stores the data collected on the user device memory considering any technical and/or regulatory constraint, for example, privacy, which can limit the amount and/or the type of data that may be retained. It also aims to protect data from corruption or deletion, which the end user or an unauthorized user can groped to run in the case of an identity theft? simulated or unsimulated fraud.

A backend communication module 12 enables communications with the backend system, i.e. the transaction verification system. Can? also manage technical and/or regulatory constraints that limit the quantity? and/or the type of data that can be transferred from the user device to the backend. The backend communication module transmits user verification data, including first user behavior data and second user behavior data, from the device to a transaction verification system.

Figure 3 ? a flowchart showing a method for processing data in a user device to generate user verification data for use in a transaction verification system, according to steps S3.1, S3.2, S3.3 and S3.4 . ? clear that said method ? a computer-implemented method.

Figure 4 ? a schematic diagram showing an example transaction verification system 2.

The transaction verification system 2 ? configured to process the first user behavior data and the second user behavior data, received from the user device 1, to provide verification of a given transaction.

As ? As can be seen in Figure 4 , the transaction verification system comprises a user device communication module 15 for enabling reception of the first user behavior data and second user behavior data from the user device, and a customer and user profile module final 16 configured to store the first and second user behavior data.

The transaction verification system 2 comprises a data processing module 17, including modules for summarizing 18, aggregating 19 and combining 20 of data, and including a module for determining data processing rules 21, which can be determined as part of an artificial intelligence system. The data processing module 17 ? configured to determine data processing rules to be applied by the user device 1 and to send data, via the user device communication module 15, indicating the data processing rules to the user device 1.

The transaction verification system includes a transaction validation module 22 configured to provide an estimate of the probability that a given transaction involved a given user by processing the first and second user behavior data.

The user device communication module 15 mirrors, on the backend side, the communication module present on the user device, i.e. it takes care of communications with the user device.

The customer and end user profile module 16 stores information regarding the customer and the end user following the transaction verification such as, for example, the quantity and/or the type of data that can be stored and transferred to the backend in compliance? with the privacy consent accepted by the end user.

The data storage and protection module 24 stores the collected data on the backend after they are transmitted from the user device to the backend, considering technical and/or regulatory constraints that may impose to limit the quantity? and/or the type of data that may be retained.

The data processing module 17, which can? include artificial intelligence features and pu? be referred to as data processing module and artificial intelligence, pu? perform on the backend side the same functions, i.e. summarizing, aggregating and combining, as the corresponding module on the user device side whenever, for example, the requested data on the user device is no longer available. available, while a copy of that data remains available on the backend side. However, this module on the backend side determines the AI and/or data processing rules that the corresponding module on the user device side should enforce. Are the rules determined centrally and, subsequently, is the actual application of the rules ? delegated to the user device.

The transaction validation module 22 ? a form that can? confirm whether or not a disputed transaction was actually a case of fraudulent authentication, simulated or unsimulated, with some degree of confidence.

The customer communication module 23 implements the interface between the customer's IT systems and the transaction verification backend, where the customer can request that a transaction check be performed on a disputed transaction, and the customer receives the result of the check as well as as provided by the transaction validation module. The client ? an?entity? which requires verification of the transaction.

The above list does not ? intended to be comprehensive: some elements may not be present on some user devices, while additional elements may be present, particularly if in the future new technologies will be commonly integrated into user devices.

Examples of the summary 7, aggregation 8 and combination 9 functions are as follows. The summary function transforms raw data, typically in normalized form, into summaries that maintain some key elements that may be needed as input by other functional modules. For example, a facial recognition function can capture raw data originating from a camera and determine if the face of the person using the device matches a person ?A? instead? to a person ?B?. As another example, a suitable function can? determine if a certain text on the device ? been entered by typing with one hand or both hands, or using only a few fingers for example.

Aggregate function 8 performs statistical analysis on data, raw or already summarized, to subsequently identify typical ways of using the device. For example, a function pu? evaluate the average length of text messages typed on messaging systems, since some users tend to split a long message into short messages, while other users type a single long message instead. As another example, a function can? evaluate if facial recognition always identifies the same person in front of the device (probably the usual user of the device) or if the device is used frequently by different people.

The combine function 9 allows you to combine data originating from multiple elements of the user device, for example sensors, raw or already summarized or aggregated, into new data types, which can later be further summarized, aggregated or combined again. For example, information related to keyboard usage, such as typing with multiple? fingers or not, scrolling, and cos? away, and the video data can be combined in such a way that the user recognition uses both information together.

In general, there may be different levels of data processing, aggregation and combination, even further combined, in order to better serve the other modules with useful information.

The above function can be implemented using two different approaches, which are not mutually exclusive and which can be combined: programmed algorithms and artificial intelligence (AI) algorithms. Using programmed algorithms, the outputs, i.e. the processed data, are calculated by applying an automatic sequence of instructions, mathematical expressions, conditional expressions, etc., which basically correspond to the functions provided by computer programming languages. Using artificial intelligence algorithms, the outputs are the result of the application of rules that derive from the experience that the computer system acquires from the processing of previously collected existing data sets. Machine learning, where experience from existing training datasets is transformed into data processing rules to be applied to future datasets, can be a component of AI algorithms.

Both approaches make use of rules: in programmed algorithms the rules are represented by instructions, mathematical expressions, etc., while in an Al context they are represented by various means, such as neural networks having a certain topology and appropriate weights on the connections between the nodes of the net. On the user device side, these rules are simply enforced. The corresponding data processing and artificial intelligence module on the backend side ? instead mainly dedicated to determining the rules to be applied later on the user device side.

The user behavior module ? conceptually an additional data processing/AI module that performs further aggregation; However, ? specifically designed to identify the types of usage patterns of the device during the days and weeks. These are certain indicators of user behavior, such as identifying device usage, how much the device is used (for example: off; idle; charging; messaging; communicating by phone; surfing the web; reading emails; etc.) and what times of day and what days of the week is this done, typical lighting conditions and background noise, typical places visited, determined using GNSS, as well as? other means (e.g., WiFi SSID, nearby Bluetooth devices, etc.), and typical keyboard and mouse use (keystrokes or scrolling; using one or two hands and/or specific fingers for typing, etc.). The transaction behavior module 11 performs similar functions to the user behavior module 10, however the functions are specifically based on data collected over a period of time before, during and after a transaction is made. Since a transaction can start at any time and requires availability? of data for a period of time before the transaction begins, a circular store is used as a buffer to store the data requested when the transaction begins. The purpose of this module ? determine user behavior specifically during customer-related transactions.

In a first scenario, all collected and stored data is sent to the backend just a communication channel to the backend ? available. This communication setting? optimal to ensure the availability? of data to the backend to perform transaction verifications, even if the user device is destroyed or data is compromised, either accidentally or through deliberate sabotage. However, it may not be possible to use this setting due to regulatory constraints (for example, privacy).

In a second scenario, the data remains stored on the user device, and only a minimal set of data is transmitted to the backend when a disputed transaction occurs. This communication setting? the "P? safe from a privacy point of view, however ? the "P? vulnerable to device damage/sabotage.

This compromise between the two above extremes of the first and second scenarios? implemented by this module and ? controlled, together with all other configuration settings, by the customer and end user profile module present in the backend.

This module also communicates locally (i.e., on the user device) with the customer?s application, i.e., with the software running on the user device to perform transactions. Unique transaction IDs are assigned and shared between the client?s application and the transaction verification system. It also takes care of getting the user to log in to backend systems using a single sign-on process (SSO), i.e. a single login that works for both the customer's application as well as the client's application. for transaction verification features working in the background.

User device communication module

This module mirrors, on the backend side, the communication module present on the user device. Check the configuration of the communication module on the user device, so that transmissions take place according to the appropriate rules and the compromise between privacy and availability? guaranteed data. It also receives the data collected and sent by the backend communication module.

Data storage and protection module (backend side)

This module stores the collected data on the backend after they are transmitted from the user device to the backend, considering technical and/or regulatory constraints (for example, privacy) that may impose the limitation of the quantity? and/or the type of data that may be retained. A database is used to efficiently store and retrieve data. This module also implements the data retention policy on the backend side depending on the rules defined as part of the customer and user profile module (see below).

Data Processing and Artificial Intelligence (AI) module (backend side) This module can? perform on the backend side the same functions (i.e., summarizing; aggregating; and combining) as the corresponding module on the user device side whenever, for example, the requested data on the user device is no longer available. available, while a copy of them remains available on the backend side. In other words, can replicate, on the backend side, all data processing functions available on the user device side, provided that the corresponding input data is available on the backend side.

This module can also assist the transaction validation module (see below) in drawing conclusions about a disputed transaction. Both programmed and artificial intelligence algorithms can be used to implement decision assistance algorithms that determine the probability of that a certain transaction is impacted by fraudulent authentication (simulated or not), based on suitable data processing rules.

Another important function of this module ? determine the data processing rules that the corresponding module on the user device must apply.

Centrally determining data processing rules has several advantages:

? Datasets originating from many (in principle, all) user devices can be used to analyze and compare different characteristics and behaviors and, consequently, to identify more user-dependent or user-independent rules. accurate that can be applied;

? The application of new rules can? be simulated before distributing the rules to user devices, in order to evaluate the effective improvements that the new rules can produce after they are activated;

? Artificial intelligence algorithms require training datasets to be submitted to computer systems, so that they learn from experience and determine the best rules to apply to new datasets to be processed. The availability of large data sets originating from many user devices ? crucial to select the most training datasets? significant. Furthermore, the machine learning process ? usually intense calculations and, consequently, ? compatible with backend data processing (for example, using powerful servers), while ? incompatible with the quantity? limited computational resources typically available on user devices;

? Once ? completed the machine learning process on the backend side and the AI rules are determined, rules can be transferred to the user devices, so that the AI calculations are performed on the user device. In fact, opposite to the machine learning phase, the application of AI rules? generally not very computationally intensive and, as a result, AI computations can also be performed on the user device side after the applicable rules are transferred from the backend to the user device.

The data processing and artificial intelligence (AI) 17 module can Also include features to manage its capabilities, such as testing programmed algorithms, selecting training datasets, presenting training datasets to candidate machine learning networks, selecting test datasets, and evaluating training results. ?training using such datasets, and so? Street.

Customer and end user profile form

This module stores and manages all the information concerning the customer and the end user following the transaction verification. The rules that must be applied to the specific customer and for the specific end user regarding the quantity? and/or the types of data that can be stored and transferred to the backend, as well as the applicable backend data retention policy, are managed by this module in accordance with with technical constraints, as well as? according to the privacy consent accepted by the end user.

Transaction validation form

Seen from the customer's point of view, this is the module pi? important because? ? one that draws conclusions about a disputed transaction, and which confirms (or does not confirm) that a disputed transaction was indeed a case of fraudulent authentication (real or simulated). To make a decision, this form ? assisted by the data processing and artificial intelligence (AI) module (backend side) through its decision assistance algorithms, programmed or based on AI.

Like all detection systems, a decision is made based on elements that can provide a certain degree of certainty about the decision, which can don't always be 100%. This module also provides the customer with information about the degree of security achieved and about the context information used to determine this degree of security, so that a human operator of the customer can further evaluate the elements provided, and possibly cancel the decision made automatically by the system. Any changes caused by human customer operators ? recorded together with the identification of the human operator who made the changes, so that everything is recorded and traceable.

Customer communication form

This module implements the interface between customer IT systems and backend transaction verification. Basically ? an interface for application programs (API) that the customer can? leverage to integrate the transaction verification system with your IT systems and build, on top? of this low-level interface, the graphical interfaces for the operators of the customer, as well as? for end users (if needed).

Collaboration/Communication

Figure 5 shows a collaboration diagram for activating a new user. The user or the end user? typically the person who is supposed to execute the transaction through a user device. This person ? typically the customer of the bank or credit card organization or other organization using the transaction verification method to possibly verify disputed transactions.

The client ? typically the bank, credit card organization or other organization (for example, a service provider that provides transaction verification service to other organizations) using the transaction verification method to possibly verify disputed transactions .

As shown in Figure 5, when a new end user is activated by a customer (for example, a new bank account or credit card holder), the first communication occurs between the customer's IT systems 25 and the customer communication module 23. The customer's IT systems, via the communication interface, inform the transaction verification system that a new end user is to be added, all relevant information (configuration settings for data collection, data transmission, privacy consent, parameters for SSO through the App, etc.) are provided to the customer communication module, which then communicates with the customer and end user profile module 16, so that a user profile is created for this user and stored permanently. The completion of the operation? later confirmed through the system to the creator.

The user is then supposed to download the customer app (or equivalent customer application software to run on the user device). User device modules for transaction verification are integrated into the customer's application software. The end user logs into the customer application and, through SSO, the end user is also identified and registered for transaction verification functions. When this stage occurs, additional user initialization functions are performed, as shown in Figure 6.

At the time of the first access, a communication channel is established between the customer and end user profile module 16 in the backend and the data storage and protection module on the user device, with the involvement of the user device communication module 15 and the module backend communication module 12, such that the user device is programmed to collect and send data according to the defined rules (including the data processing rules defined by the data processing and artificial intelligence module on the backend side). This includes (shown with a larger dashed arrow in the diagram above) a handshaking between the two customer and end user profile modules (the one in the backend and the one on the user device side), such that the information that follows to the specific user device (for example, which sensors are present on the device and which sensors are not present, what are the characteristics of the sensors, etc.) are added to the user profile, and the most common data processing rules? appropriate are selected accordingly. On the user device side, the customer and end user profile module 16 then instructs the data processing and artificial intelligence (AI) module 6 (user device side) about the data processing rules to apply. If something changes over time related to the end user profile, including the data processing rules (for example, based on collected data some improvements to the data processing rules may be introduced), all changes are propagated from the backend to the end user device or vice versa despite the same handshaking mechanism.

Once the user device ? fully initialized, all modules start collecting, processing and eventually sending data to the backend so? as required by your functions and the defined user profile including the associated data processing rules. Whenever a transaction is made, the data is handled as follows: as requested and a unique transaction ID is assigned to the transaction, so that the transaction can be traced at a later point in time.

Figure 7 shows the collaboration diagram regarding a disputed transaction. When a disputed transaction takes place, the IT systems of the customer 25, via the communication interface, submit a request for validation of a certain transaction ID to the customer communication module 23. The customer communication module 23 activates the transaction validation module 22, which activates the data processing and artificial intelligence (AI) module (backend side) 17, which in turn retrieves the requested data from the data storage and protection modules 24 , 13 (the one on the backend side for data already transmitted to the backend, the one on the user device side for data not yet transmitted to the backend). Data recovery from the user device can not be immediate, as the user device pu? be turned off or not connected, requests for data to be transmitted from the user device are then queued to be satisfied as soon as possible. connection to the end user device be established. When the data is available and the response from the transaction validation module ? ready, the result is communicated to the customer's IT systems by the customer communication module.

Collaboration diagrams do not include the case where a backend ? shared among multiple customers, such as, for example, the case in which a transaction validation service ? provided by an?entity? (i.e., a Transaction Validation Service Provider - TVSP) to multiple customers (various banks, credit card organizations, online payment providers, etc.). A TVSP approach can be useful since? Sharing many end users from multiple customers provides larger datasets. great for testing and refining data processing systems and, in the case of artificial intelligence systems, provides larger datasets. great for training and testing AI algorithms.

Backend system provisions

Two exemplary backend system arrangements (dedicated and shared backend) are shown in Figures 8 and 9.

In the case of a dedicated backend, as shown in Figure 8, the backend itself 26 can? logically be considered as part of the customer's IT systems 25, in particular if ? co-located and physically integrated with them.

In the case of shared backend, in the case of Figure 9, the logical differentiation between the backend 27 and the different IT systems of customers ? important, whether they are physically co-located or even when they share the same cloud servers. In this case the customer communication module ? logically and physically connected to the IT systems of multiple customers 28, 29, 30 and ? prepared to receive transaction validation requests from each of them. Provides relevant responses that maintain the necessary logical separation between requests originating from different customers.

It should be understood that any characteristic described in relation to any example can be used alone or in combination with other features described, and pu? also be used in combination with one or more? characteristics of any other of the examples, or any combination of any other of the examples.

Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the attached claims.

Claims (20)

Claims 1. A method for processing data in a user device (1) to generate user verification data for use in a transaction verification system (2), comprising the steps of: to derive (S3.1) first user behavior data from a first plurality? of sets of data, each of which ? generated by a plurality? of different elements (4) of the user device (1), and each of which ? representative of a user interacting with the user device (1); identify (S3.2) at least a first time interval related to a transaction involving a user of the user device (1); to derive (S3.3) second user behavior data from a second plurality? of sets of data, each of which ? generated by the plurality? of different elements (4) of the user device (1), and each of which ? representative of a user interacting with the user device (1) during at least the first time interval; And transmitting (S3.4) user verification data, including first user behavior data and second user behavior data, from the user device (1) to a transaction verification system (2). The method according to claim 1, comprising a step of identifying the first time slot as the time slot during which the transaction takes place. The method according to claim 1 or claim 2, comprising the steps of: identifying a second time interval as a time interval before which the transaction occurs; and/or identify a third time interval as a time interval after which the transaction takes place, in which the second plurality? of data sets ? each representative of a user interacting with the user device (1) during the first time interval and the second and/or third time interval. The method according to any preceding claim, comprising collecting the second user behavior data in response to receiving an indication that ? a transaction is in progress. 5. Method according to any one of claims 1 to 3, comprising the steps of: storing user behavior data in a storage system (13) on the user device (1); receiving timing data indicative of the first time interval from the transaction verification system (2); And retrieving the second user behavior data from the storage system (13) on the basis of the timing data. 6. A method according to any one of the preceding claims, wherein the derivation of the first and second user behavior data comprises the use of a hardware abstraction functional module (5) configured to transform data generated by the plurality of user behavior data. of different items (4) of the user device (1) into transformed item data having a normalized format for the transaction verification system (2). The method according to claim 6, wherein the derivation of the first and second user behavior data comprises the use of a data processing functional module (6) configured to perform summarization, aggregation and combination functions on the transformed item data to generate processed item data. The method according to claim 7, wherein the derivation of the first user behavior data comprises using a user behavior functional module (10) configured to extract information about a typical user behavior from processed feature data related to the first plurality of data sets. The method according to claim 7 or claim 8, wherein the derivation of the second user behavior data comprises using a transaction behavior functional module (11) configured to extract information about a user's behavior from transaction data elaborate elements related to the second plurality? of data sets. 10. Method according to any one of the preceding claims, wherein the plurality? of several elements (4) of the user device (1) comprises a sensor. 11. Method according to claim 10, wherein the plurality? of different elements (4) of the user device (1) includes one or more? items selected from: a camera; a microphone; an inertial sensor; a temperature sensor; a fingerprint sensor; a keyboard; a touchpad; a mouse. 12. Method according to any previous claim, in which the plurality? of different elements (4) of the user device (1) comprises a radio interface of the user device (1). 13. Method according to claim 12, wherein the plurality? of different elements (4) of the user device (1) includes one or more? items selected from: a WiFi interface; a GPS/GNSS interface; a wireless cellular interface; And an NFC interface. 14. Method according to any one of the preceding claims, wherein the plurality? of different elements (4) of the user device (1) includes one or more? items selected from: a screen interface; a touch screen interface; an operating system; a USB interface; a timer. The method according to any one of the preceding claims, comprising receiving data indicating data processing rules from the transaction verification system (2) to derive the first user behavior data from the first plurality? of data sets and derive the second user behavior data from the second plurality? of data sets. 16. System for verifying a transaction after ? occurred the transaction comprising a user device (1) configured to execute the method according to any one of claims 1 to 15 and the transaction verification system (2). The system according to claim 16, wherein the transaction verification system (2) is configured to process the first user behavior data and the second user behavior data to provide verification of a given transaction. The system according to claim 16 or claim 17, wherein the transaction verification system (2) comprises a customer and end user profile form (16) configured to store first and second user behavior data. The system according to any one of claims 16 to 18, wherein the transaction verification system (2) comprises a transaction validation module (22) configured to provide an estimate of the probability? that a given transaction involves a given user by processing the first and second user behavior data. The system according to any one of claims 16 to 19, wherein the transaction verification system (2) comprises a data processing module (17) configured to determine data processing rules to be applied by the user device (1), and to send data indicating the data processing rules to the user device (1).