IT201900003249A1 - SYSTEM AND METHOD FOR IMPLEMENTING SECURITY PROCEDURES IN THE EXECUTION OF ELECTRONIC TRANSACTIONS - Google Patents

Description

Field of application of the invention

The need to ensure the execution of electronic payments in complete safety is now known. New technologies lead to an increasingly massive use of various devices such as PCs, kiosks, ATMs, Smartphones, wearables for the execution of economic transactions. In this scenario increasingly monopolized by the use of these tools, attacks directed at the devices themselves and the related communication networks are increasingly widespread by ill-intentioned people who want to steal these electronic communications in order to divert and send the related payments to non-third parties. authorized.

Known art

The electronic payment techniques that are present on the market can be divided into two main categories: circuits and networks. The first category includes the so-called star-center methodologies where the service manager prepares his own infrastructure to which all users subscribe upon registration, among these we can include VISA, MasterCard, AMEX, Jiffy, Satispay, MyBank (at least in the old versions for the last three systems in the list) which move the sums from one account to another between the various subscribers. These transactions can take place instantaneously or alternatively they are subject to instant notification operations and in the latter case to back-end operations that move the sums between the respective financial institutions counterparties not for single transactions but for massive operations subject to an account statement. in the various daily cut-offs. In any case, the experience of the end user with regard to the transaction is almost immediate as the amount paid or credited to the amount received is immediately debited from the account.

In the second category, on the other hand, interbank systems, subject in some cases to intermediate clearing and settlement steps, which connect the various banks which in turn hold the relative current accounts of their customers. In the latter case, consider the SEPA Inst or SCT Inst and the BANK-NOTES® system, by the applicant, which make an instant transfer of funds from one account to another, setting the entire supply chain to perform single and instant transactions . The latter chain can also be represented by nodes placed on the network, or each bank a node, which join together the various banks by applying the so-called or called blockchain. In the latter case, each node located in each bank and between one bank and another receives the transaction message, records it, checking the date, the sender and the recipient, with itself and forwards it transparently to the node until reaching the beneficiary's bank at the last node in the chain. In the event that these nodes are set for instant execution, a direct connection will be obtained between the payer's bank and the recipient's bank. This description does not deliberately enter into the issue of transaction encryption which can be managed through the use of public and private encryption keys in the possession of the respective parties.

The exchange of information and therefore the payment as mentioned above takes place, in particular, on the move, using modern smartphones, or similar, up to wearables external or internal to the human body, which programmed for this purpose first exchange information among themselves. of mutual recognition followed by commercial information relating to the transaction from which the triggering of the payment from one device to another starts until the execution and successful completion of the transaction itself is confirmed.

To carry out these exchanges of information, various communication techniques are used, among these it is possible to conveniently make use of particular standards or transmission technologies among these for example: NFC, Bluetooth, WiFi, IrDA, BarCode, QrCode. Further detailed information on the two most promising and most used technologies on the market is recalled below:

NFC: https://en.wikipedia.org/wiki/Near-field_communication#ISO_/_IEC

QrCode: https://en.wikipedia.org/wiki/QR_code

These standards that can be used for the purpose equivalently have, in particular conditions, peculiarities that facilitate or not the execution of the transaction between the parties, improving its operation. For example, the exchange of information through images by creating visual encodings, see respectively the BarCodes or even better the QrCodes, are read and then decoded through appropriate cameras present on modern devices. There are also other so-called proximity technologies that create radio codes that are read by bringing the various devices together and in particular the backs of the two smartphones where the antennas of the devices are located. This technology called NFC acronym for Near field communication is, in the applicant's opinion, particularly suitable for making payments that have an execution flow very similar to an exchange of cash. In fact, while the QrCode can also be used in off-line situations by reading, for example, the code for the execution of the payment on the supplier's invoice, with NFC it is possible to automate, simplify and speed up transactions. simply by bringing the two devices together. In particular, NFC technology finds its best use between a POS (point of sales) and a credit card equipped with a chip where the information of the payer (payer) is stored inside these: credit card number, holder , deadline. It should also be considered that this operation can similarly be performed by smartphones that adopt NFC systems that adopt the so-called technologies HCE - Host card emulation - which allow you to save all credit card data inside the mobile phone thus avoiding having to carry with physically the credit card itself. The operation, in detail between the two devices, takes place as follows: on the POS the merchant, approaching the card at a useful distance, reads the information contained in the credit card chip with his antenna, types the amount due and requests the circuit if the Payer has sufficient availability to execute the transaction. Once positive consent has been received, it triggers the payment operation by charging the cost to the payer's card which, depending on the value purchased, may or may not be required, for security reasons above certain amounts, to provide the PIN or the OTP or may, further , confirm the operation with the various biometric verification systems available on the market. The payment ends with the issuance by the beneficiary (Payee) on his POS of a receipt where the payer signs the original, thus providing further proof and definitive confirmation of the payment transaction or in some cases by typing in the PIN to be part of the payer.

More simply as shown in the figures below.

In the diagram shown in Fig. 1 the customer (101) pays (1) the seller (102) using his credit card. The seller's POS (102) transmits (2) the card data and the amount of the transaction to the network of the card circuit manager (103), which sends them (3) to the card issuer (105) to obtain authorization (4 ) to proceed by verifying the validity of the card and the availability of funds. In case of approval, the vendor's POS (102) receives (5) authorization so that (102) prints (6) the receipt that 101 must sign or confirm with a PIN. The vendor POS (102) transmits (7) the information on the transaction to (104) to the acquirer / bank that manages the POS. (104) corresponds (8) to (102) the funds involved in the transaction with (101). Subsequently, in the phase of reconciliation or clearing of the flows between issuer (104) and acquirer (105), the amount of compensation (11) that may be necessary to settle the balance is determined in agreement with the card circuit manager (103). (104) withholds (12) the purchase amount from the buyer's account (101). The system in question has also become commonly used for the man on the street who similarly finds simplicity and speed on a par with exchanging banknotes.

And yet another example, in fig. 2, of a payment solution based on the 4 corners scheme.

The payment transaction, described below and represented as follows, highlights a transaction in its complete form. The same takes place in the exchange of information between the terminals of the seller (208) and of the customer (201), (1). This exchange can take place with NFC, RFID, WiFi QrCode technologies among the most common, and consists in the exchange of synchronization information between devices (2) in commercial information (3) consisting in the description of the goods sold in the price and in the exchange of the respective IBANs . Below, the customer's device (202) (201) set up for on-line payments connects (4) to his current account at his bank (203) where he forwards (4) the data relating to the purchase, the amount to be paid and the IBAN corresponding to the seller's current account. Subsequently, to complete and guarantee the operation, the customer enters the device PIN or the OTP code (On Time Password) provided by his bank (5) the payment in favor of the merchant (208) at the bank (206) on the account (207). The vendor's device or POS (209) connects (6) in turn to (207) and checks the new balance on its account generated by the customer's transfer so as to find the outcome of the payment in its favor and the relative correct origin with direct reference to the good just purchased. Upon receipt of the payment the POS (209) issues (7) payment receipt and the seller (208) delivers (8) the goods sold to the customer (201).

These operational scenarios that are simple in themselves lend themselves to being the object of attacks by ill-intentioned people who would tend to divert payment to other unauthorized recipients and also vary the amount of the transaction. In this case we are talking about a family of attacks called MAN IN THE MIDDLE which more precisely are divided into 2 sub-species of which the second in turn is divided into 2 further types of attacks:

Man in the Middle: https://en.wikipedia.org/wiki/Man-in-the-middle_attack

Man in the Browser / Man in the APP: https://en.wikipedia.org/wiki/Man-in-the-browser

In particular, in the first case, the attacker intervenes and intercepts the communications between the two parties on the network and modifies the information that is exchanged.

In the second case, however, the presence of a Virus inside the APP or a Virus on the Browser occurs which, as in the previous case, modifies the User (Client) communications to the server. In both cases just mentioned, these changes take place in a hidden way so that the parties are not even aware of what happened. From this it is easy to understand that if these transactions are not effectively countered, there would be enormous damage for the banks and for the customers themselves. In addition to this, there would be a progressive abandonment in the use of these technologies due to the lack of trust that customers would no longer place in the banks and circuits in the presence and continuation of these frauds.

Given the importance of this problem, various solutions have been implemented and coordinated that all or in part together mitigate this risk, in this sense:

• Username password

• Biometric data of the user

• Mutual Authentication

• OTP

• Token

• Smart cards, Digital certificates

• Anti-Virus or Anti-malware applications

• IP-Geolocation

• Device profiling

Some of these solutions can be considered effective others less and in this case further advisable behaviors to be maintained would be:

• Maintain and use the home banking devices separately

• Keep your Browser mounted on a USB drive

• OTP tokens with signature that verify the transaction on a second Out of Band (OOB) channel

• Monitor user behavior and block any transaction in the presence of behavior other than the usual on the part of the user

While the first two solutions have remained pure and simple advice over time, it does not seem that these behaviors have become part of the common and daily use of the user, the third and fourth solution as reported above have found confirmation on the market and are implemented in the various payment transactions.

As for the OOB solution through the system called OTP signature, there are several companies which offer different solutions that uniquely bind the OTP to the transaction. Among these we can find RSA which proposes a software solution that allows to show on the payer's monitor, before the final payment order, all the data of the transaction itself. Another solution promoted by VASCO HW consists in concatenating the amount and the IBAN of the beneficiary which are also shown on the payer's monitor and finally another solution by ALIAS LAB - Securecall where a speech synthesis system contacts the payer, on your phone, to which the payment transaction that must be confirmed is read in sequence. All three of these solutions require the user to verify the consistency of the transaction so as to be able to approve and then generate the OTP Signature so that the bank can proceed safely with the execution of the payment. The proposed solutions would appear safe and sufficient for the purpose but, as indicated in the jargon, they are not frictionless. These procedures in fact force the user to carry out further heavy checks after the user had to log in to access the service by typing various passwords or PINs or biometric data, placing additional control and stress tasks on him which, especially during mobile payments, become very difficult to manage.

With regard to the fourth solution for monitoring user behavior, there are various solutions on the market which, through artificial intelligence systems, control customer behavior by keeping their habits mapped. Further these solutions have evolved in keeping under control in real-time the execution flow of the program or application which in case of attack would show abnormal runtime behavior. In this case, for example, VERACODE provides a solution called RASP (Runtime application self-protection) that blocks any attacks or dangers in real time. In this case it is a statistical and non-deterministic solution which therefore by its nature cannot be considered decisive at the most said solution can mitigate the problem.

These solutions incorporate the dictates of recent regulations, see in this sense the PSD2. As previously described, each security request is based on three fundamental hinges that establishes the necessary requirements to guarantee the exact identity of the person who uses electronic payment systems, in this case the security passes through something that is known, something that you have and again for something you are. More simply: login and password, your smartphone or token, your biometric data. The claimed invention therefore, is proposed as a system in contrast to the proliferation of the so-called TROJAN BANKERS which can infect the equipment used simply by surfing the net and which affect hundreds of thousands of unfortunates every year by carrying out illegal transactions. The application that we intend to describe and claim below intends, by improving its safety, to solve the operational difficulties that are incurred by the user in the use of OOB solutions. Also the solution devised of the deterministic type intends to replace or further support the solutions that instead respond using artificial intelligence to attacks, after checking statistics. The claimed application can be applied not only on Desktop, but also with mobile terminals by connecting to credit card circuits or typically circuits such as Jiffy, MyBank and Satispay where the payment flow is similarly comparable.

Brief description of the invention

The invention verifies and certifies the exact execution of payments and financial transactions, through a particular and appropriate sequence and exchange of information between the paying party and the receiving party, the eventual circuit, the network, the respective banks through the implementation of particular telephone services. In particular, the purpose of the invention is to allow the so-called initiative payments in complete safety. The application that you intend to claim as mentioned above can also be used in the presence of circuits or networks that connect the parties involved in the transaction, the Payer and the Payee.

Each sector operator will immediately agree on the simplicity of use, speed and cost-effectiveness of the invention and in particular on the security that the transaction receives from the escalation of the various implementation phases that individually, or one after the other, or all together allow for implementation. of the invention. The system designed only allows the person (s) who actually have the right to execute the transaction to execute it.

The invention is aimed at a scenario where a payer equipped with an IBAN enabled to perform services in Home Banking or equipped on their own device with an APP enabled for the same purpose wishes to make payments to other account holders of the same bank, of the same circuit. or to other banks or other circuits. The account holder is therefore enabled, subject to adequate verification by the bank or financial institution, to remotely perform any arrangement, verification, payment operation possible from his / her account.

The application can also be implemented to acquire data by means of the latest technologies including NFC, QrCode or finally OCR.

https://en.wikipedia.org/wiki/Optical_character_recognition

As will be seen later, the security of the system will be guaranteed through special recognition and certification services based on the second channel through the telephone network.

The invention carries out exchanges of information between the device and its bank and between its bank and the beneficiary and among these the following can be chosen: the date and time in which the transaction took place, the geo-location data, the MAC code, the IP address, the telephone number or the USIM, the Tax Code or digital ID, and can be done automatically with the exception of the PIN or OTP which must be entered directly on the display of your device. The steps for entering the PIN or OTP codes could, in turn, be automated or avoided as will be seen below by specific choice by the user or by the choice of banks which could in turn further subject the recognition phase. of the user's ID to a further step of speeding up with the aid of the user's biometric data.

Fig. 3 represents an overall version of the various implementation steps of the different safety levels obtainable from the invention. These are different processes that can be coordinated and used individually and separately or take place all together, depending on the degree of safety required.

Fig. 3 highlights the 19 phases, including three different subsystems, necessary to perform the verification of a payment triggered autonomously by the Payer (so-called initiative payments).

Phase (1): The Payer (301) by accessing Home banking with their Desktop (302) or alternatively using the app installed on their smartphone (302) prepares a transfer order for their bank (304) to be debited on the own current account (303). In this phase (301) communicates the Payee header, the Payee IBAN, the amount to be paid, the reason for payment, the Payee (309) mobile phone number (310).

Phase (2): The bank (304) performs a formal check on the order just received and places said order in stand-by on the DB (312)

Phase (3): The bank (304) through its messaging server (314) by accessing the DB (312) prepares a message which it sends to the Payee (309) which is prepared as in the following example:

Bank 123XYZ - P * R * paid you € 200 if you accept call 020808 followed by the 4 final digits of your IBAN starting with IT45 * PRIVACY,

and where in respect of privacy, P * R * stands for Paolo Rossi payer (301) and IT45 * stands for the destination country of the IBAN (308) of the payee (309) and 45 corresponds to the checksum of the IBAN (308 ) of the payee (309).

Phase (4): The Payee (309) with its apparatus (310) calls the Pabx (311) communicating the last 4 digits of the IBAN (308) to the GNR number of the Pabx.

Phase (5): The Pabx (311) does not answer the call - it does not provide the ACK - but in the signaling flow of the same call it reads the so-called INFO Element at the connection interface with adequate equipment for reading the transmission protocols where it contains the data / number of the caller CLI or Calling party number - in this case the CLI of (310) and the data / number of the called CLDn or Called party number - in this case the CLDn of the PABX of the bank (304) which corresponds to the GNR (restricted numerical group), i.e. the radical of the number assigned to the PABX (311) followed by the CRO communicated by (309) the last 4 digits of its IBAN (308)

Phase (6): The Pabx (311) discriminates on the CLDn entered by the Payee (309) the GNR number from the CRO and puts the CRO in stand-by in the DB (313)

Phase (7): The bank (304), randomly, asks (302) to choose the digits corresponding to 4 positions contained in the Payee IBAN (308)

Phase (8): Based on the requests of the bank (304) the device (302) selects the 4 numbers on the Payee IBAN, creating a search key that can be used on the TOKEN table (305) preloaded on the device (302) and on the systems of the bank (304) and where, by accessing, it will find the corresponding key to be sent to the bank (304).

Phase (9): The Payer (301) with the device (302) in an automated manner carries out the validation telephone call to the GNR SP Channel 2 number (316) by following the key as determined above to the Pabx number (311)

Phase (10): the bank (304) receives the call to its Pabx (311) but does not answer the call - it does not provide the ACK - but in the signaling flow of the same call it reads, at the connection interface with adequate reading of the transmission protocols, the so-called INFO Element where, in it, the data / number of the caller CLI or Calling party number are contained - in this case the CLI of (302) and the data / number of the called CLDn or Called party number - in this case the CLDn of the bank's PABX (304) which corresponds to the GNR (restricted numerical group), i.e. the radical of the number assigned to the PABX (311) followed by the CRO communicated by (301) referring to the key for the access to the TOKEN table resident on the device (302) and on the bank devices (304)

Phase (11): once the access key to access the TOKEN table has been determined, the bank (304) accesses it and verifies the corresponding numerical data, correlating them to the positions chosen randomly, previously, on the Payee IBAN in its possession and stand-by the CRO code as determined on the DB (312).

Phase (12): the bank (304) through its messaging server (314) based on the transfer order received from (301) responds to the device (302) by sending a message such as the following:

BANK 123XYZ - Bank transfer to M * B * € 200 for confirmation call 020808 followed by the 4 final digits of the IBAN of M * B *

or alternatively as in another example that follows:

BANK 123XYZ - Bank transfer to M * B * € 200 for confirmation call 020808 followed by the final 4 digits of M * B * mobile phone

and where in respect of privacy, M * B * stands for Mario Bianchi as payee (309).

Phase (13): the Payer (301) by means of (302) calls the Pabx (311) of the bank (304) by following the GNR number with the CRO consisting of the last 4 digits of the IBAN (308) of the payee (309) or alternatively the last 4 digits of the mobile number of (310)

Phase (14): the bank (304) receives the call to its Pabx (311) from (302) but does not answer the call - it does not provide the ACK - but in the signaling flow of the same call it reads, at the interface connection with adequate equipment for reading the transmission protocols, the so-called INFO Element where, in it, the data / number of the caller CLI or Calling party number are contained - in this case the CLI of (302) and the data / the number of the called CLDn or Called party number - in this case the CLDn of the PABX (311) of the bank (304) which corresponds to the GNR (restricted numerical group), i.e. the radical of the number assigned to the Pabx (311) followed by the CRO communicated by (301) referable to the last 4 digits of the IBAN (308) or alternatively to the last 4 digits of the mobile phone number (310) of the Payee (309).

Phase (15): The Pabx (311) discriminates on the CLDn entered by the Payer (301) the GNR number from the CRO and puts the CRO in the DB (312) in stand-by

Phase (16): the bank (304) compares the data in stand-by in the respective DBs (312) and (313) and verifies its correctness with reference to the original payment operation arranged by (301) with Phase 1. In the event of an inconsistency, the bank (304) notifies the parties of the impossibility of making the payment and, if necessary, informs about the possible reasons.

Phase (17): in case of positive verification, the bank (304) arranges the payment forwarding it to the interbank network (306)

Phase (18): the interbank network (306) provides the various clearing and settlement functions and forwards the payment to the payee bank (307)

Phase (19): the payee bank (307) credits the sum as received from (306) on the current account (308) of the payee (310)

The operations of reading and discrimination on the telephone signaling flow referred to in the previous Phase (5), (6), (10), (11), (14) and (15) can be easily performed by positioning, for example, a Protocol Analyzer for calls depending on the type of telephone transmission used (Wireshark for IP calls and Utel Stinga for ISDN), that is: for circuit-switched transmissions by reading the transmission protocols on SS7 or DSS1 according to ITU-T Q.769 o ITU-T Q.931 while in the case of packet switching in SIP by reading the transmission protocols according to the IETF RFC 3261 "SIP: Session Initiation Protocol". In any case, the management and collection of data as read can be easily implemented through common IVRs by setting up and programming the same systems for reception and reading in telephone flows and in the execution of automated calls.

The four digits of the CRO, commonly used in the examples as data for comparison, are considered sufficient for the purpose and are the right compromise between the safety provided and the ease of execution by the end user. In any case, it should be noted that the amount of the same figures can be decreased or increased depending on the availability that the telephone network allows.

The simplicity of the system and the availability of consolidated technologies on the market that can be easily used to implement the solution are evident. The system set up in this way, by preordering the flow of the various functions in an innovative way, allows for a simple, fast and economical payment method. The arrangement of separate functions also performed on a 2nd transmission channel released from the 1st channel, that of Home Banking / APP, together with any geo-referencing checks, in any case always and in any case under the supervision of the bank (304) , makes cyber attacks on the claimed system impossible and uneconomical. The invention allows absolute certainty regarding the ID of the payer and the recipient by performing, in a separate and comparative way, a double check that protects from the so-called dangers due to MAN IN THE MIDDLE, MAN IN THE BROWSER and MAN IN THE APP .

The system thus devised is particularly suitable for certifying and guaranteeing the effective correctness of the beneficiary. The system and the method claimed here, in addition to the fact of presenting innumerable advantages in particular with regard to the User Experience which is extremely simplified, is manageable with considerable advantages compared to the other OOB systems listed in the introduction much more complex and cumbersome. Further, the system adapts to avoid the control or verification of user behavior which on a more in-depth examination could highlight in some forms a violation of user privacy. Simply sending a verification SMS by the payer's bank to the payee and / or payer to trigger the sworn procedure is simple, safe and cheap. This process, in addition to minimizing other additional tasks for the payer, becomes a courtesy message for the beneficiary that does not impact on the beneficiary's operations. In other words, we are witnessing a dual synergistic aspect where the payer's bank is guaranteed the correctness of the payment it is about to make while the beneficiary is promptly informed of the receipts he is about to receive. Such a simplified system is clearly usable by all types of users, from the most advanced to the least familiar with the use of electronic devices.

Detailed description of the invention

The invention is illustrated with the related diagrams and diagrams and highlights the same in the deemed best possible solution. These example representations are described sufficiently so that the expert in the field can easily put the invention into practice. Therefore, the detailed representation is provided as a preferred illustration but this does not imply any limitation in this regard, also specifying that any logical, mechanical variation can be made without thereby departing from the scope of protection of this patent application.

Those skilled in the art will also appreciate how much the present method can be implemented as a computer program, as a process system and thus how the method can be implemented entirely as software applications, hardware applications, or the blending of software and hardware applications.

Coming in practice to the application, the fixed and mobile devices / terminals in question can use any and any type of means for electronic communication that can make use of telephone and data networks and the main Wireless platforms including GSM, GPRS, UMTS, LTE, WI-FI, WIMAX, Bluetooth, WiFi, and nevertheless use Barcode, QRcode, RFID, NFC which, as known, correspond to transmission or communication technologies widely spread and used by normal telephone devices or smartphones. The system in question can also freely make use of so-called circuit-switched or packet-switched transmissions.

The method of the invention aims to facilitate the user in making electronic payments, primarily, to guarantee him against any attacks or fraudulent use of the equipment used. The latter equipment equipped with adequate software prepared according to the teachings of the invention allows to avoid any improper use by unauthorized persons and nevertheless proves particularly resilient to any cyber attack. The system can be applied to any payment or financial, banking and postal service, with value added (VAS, Value Added Services) that makes use of devices set up for the purpose. The system can also operate on today's payment systems that use credit cards or circuits in general.

The invention can be used to perform payments subject to batch clearing and settlement operations or to perform payments in real-time by setting the entire supply chain involved in the payment operations, including the customer's bank and that of the beneficiary and the entire interbank network in real-time so as to similarly create a direct connection between the customer and the beneficiary. The SEPA and SCT Inst systems can conveniently use the invention.

Anyone with a second or third generation mobile terminal and a bank account can be certified at any time, securely, with a few simple steps to make a payment.

The invention may include an apparatus equipped with APP that makes use of standard systems and plug-ins that allow the implementation of the following functions for security management.

The invention applies to a method that performs value-added services (distinctive VAS) where the user prepares to perform communications between devices set up as indicated below:

A) Signing, after due diligence, of a current account contract by the user in a bank for its certification and for the assignment of the relative IBAN code, where the bank correlates to said code in addition to the personal data the / the customer's telephone numbers to be used as an address for sending notifications, OTPs or any communication from the bank itself. The bank also, depending on the type of service, enables the customer for the counter-verification service via PIN, OTP or TOKEN which can be SW or HW and again through the user's biometric data

B) Enabling the above-mentioned contract for online services, on the WEB, of the Bank (Home Banking)

C) Installing the APP on the device

D) LOG procedure to the system using login data

E) Procedure for enabling services for reading and disposing of payment orders F) Password, Token or OTP device management or confirmation via biometric data

G) Verification procedure of the beneficiary by recognizing the IBAN digits, via the beneficiary party's mobile device by reading the CLDn

H) Certification procedure of the paying customer through CLI and CRO recognition generated by the payer's Bank and determined via CLDn from the TOKEN table I) Certification procedure of the beneficiary's data through CLI recognition of the payer and CROs obtained via CLDn as digit of the number of the Phone

J) Procedure for declaring the beneficiary's data through the CLI recognition of the payer and the CRO obtained via CLDn as the digit of the IBAN number of the paying party

The above functions with the exception of phases G) H) I) and J) are widely present and commonly used in daily use. The industry expert is very familiar with these systems and techniques and knows how common the use of these tools is since any bank offers its account holders Home Banking services via desktop or smartphone. The sector expert will be able to appreciate and agree on the innovative introduction of the further verification method, through a different and particular management of information and on the certification through the second channel of the respective counterparties. The comparison regarding the characteristic information of the payee, of the verification and reading of the CLI and the CLDn by the devices specially prepared by the bank or by third parties involved in this type of telephone service which, as designed in the application, allows a further methodology certification verifies who is authorized to execute the transaction and who is actually authorized to receive it.

Fig. 3 BIS SCENARIO - represents the macro areas of intervention of the system and the general scenario, the components, the parties involved and the related infrastructures.

In this case:

301 - Payer

302 - Payer's device

303 - Payer's account

304 - Payer's Bank

305 - TOKEN Table

307 - Payee's Bank

306 - Interbanking network / SEPA Inst, ACH, Cards, Blockchain

308 - Payee's Account

309 - Payee

310 - Payee's device

311 - Payer's bank derivation, IVR or PABX, or Answer Management

312 - First Payer's Bank DB and Storage

313 - Second Payer's Bank DB and storage

314 - Messaging server

315 - Mobile network

316 - Phone channel

317 - Home Banking channel / IP

In the 3 following figures, the first value of the numbering relating to the functions and apparatuses will be varied, as per the numbering of the figures. This is in order to make the interpretation of the relative description easier.

The invention consists of various implementations which have been shown as a whole in Fig.3. These improvements can also be arranged individually one by one according to the desired safety need and are therefore sectioned respectively.

Detailed figures and respective flows

In Fig. 4 - Process G - the automated procedure for the recognition and certification of the payee is detailed.

Function List

Phase (1): The Payer (401) by accessing Home banking on his Desktop (402) or alternatively using the app installed on his smartphone (402) prepares a transfer order for his bank (404) to be debited from his account current (403). In this phase (401) communicates the Payee header, the Payee IBAN, the amount to be paid, the reason for payment, the Payee mobile phone number.

Phase (2): The bank (404) performs a formal check on the order just received and places said order in stand-by on the DB (412)

Phase (3): The bank (404) through the messaging server (414) by accessing the DB (412) prepares a message that it sends to the Payee (409) which is prepared as in the following example:

Bank 123XYZ - P * R * paid you € 200 if you accept call 020808 followed by the 4 final digits of your IBAN starting with IT45 * PRIVACY

and where in respect of privacy, P * R *, stands for Paolo Rossi payer (401) and IT stands for the destination country of the IBAN (408) of the payee (409) and 45 corresponds to the checksum of the IBAN (408) del payee (409).

Phase (4): The Payee (409) calls the Pabx (411) communicating the last 4 digits of the IBAN (408) to the GNR number of the Pabx.

Phase (5): The Pabx (411) does not answer the call - it does not provide the ACK - but in the signaling flow of the same call it reads, at the connection interface with adequate equipment for reading the transmission protocols, the so-called INFO Element where it contains the data / number of the caller CLI or Calling party number - in this case the CLI of (410) and the data / number of the called CLDn or Called party number - in this case the CLDn of the PABX of the bank (404) which corresponds to the GNR (restricted numerical group), i.e. the radical of the number assigned to the PABX (411) followed by the CRO communicated by (409) the last 4 digits of its IBAN (408).

Phase (6): The Pabx (411) discriminates on the CLDn entered by the Payee (409) the GNR number from the CRO and puts the CRO in stand-by in the DB (413)

Phase (7): the bank (404) compares the data in stand-by in the respective DBs (412) and (413) and verifies their correctness with reference to the original payment operation arranged by (401) with Phase 1. In the event of an inconsistency, the bank (404) notifies the parties of the impossibility of making the payment and, if necessary, informs about the possible reasons.

Phase (8): in the event of a positive check, the bank (404) arranges the payment by forwarding it to the interbank network (406)

Phase (9): the interbank network (406) provides the various clearing and settlement functions and forwards the payment to the payee bank (407)

Phase (10): the payee bank (407) credits the sum as received from (406) on the current account (408) of the payee (410)

In Fig. 5 - Process H - the automated procedure for further recognition and certification of the Payee is detailed.

Function List

Phase (1): The Payer (501) by logging into Home banking on your Desktop (502) or alternatively using the app installed on your smartphone (502) prepares a wire transfer order for your bank (504) to be debited from your current account (503). In this phase (501) communicates the Payee header, the Payee IBAN, the amount to be paid, the reason for payment.

Phase (2): The bank (504) performs a formal check on the order just received and places said order in stand-by on the DB (512)

Phase (3): The bank (504), randomly, requests (502) the digits corresponding to 4 positions contained in the Payee IBAN (508)

Phase (4): Based on the requests of the bank (504), the device (502) chooses the 4 numbers on the Payee IBAN, creating a search key that can be used on the TOKEN table preloaded on the device and on the bank's systems (504) and where, by accessing, you will find the corresponding key to be sent to the bank (504)

Phase (5): The Payer (501) with the device (502) in an automated manner makes the validation telephone call to the GNR Channel 2 number (516), following the key as determined above to the Pabx number (511)

Phase (6): the bank (504) receives the call to its Pabx (511) but does not answer the call - it does not provide the ACK - but in the signaling flow of the same call it reads, at the connection interface with adequate reading of the transmission protocols, the so-called INFO Element where, in it, the data / number of the caller CLI or Calling party number are contained - in this case the CLI of (502) and the data / number of the called CLDn or Called party number - in this case the CLDn of the bank's PABX (504) which corresponds to the GNR (restricted numerical group), i.e. the radical of the number assigned to the PABX (511) followed by the CRO communicated by (501) referring to the key for the access to the TOKEN table resident on the device (502) and on the bank devices (504)

Phase (7): once the access key to access the TOKEN table has been determined, the bank (504) accesses it and checks the corresponding numerical data, correlating them to the positions chosen randomly, previously, on the Payee IBAN in its possession and stand-by the CRO code as determined on the DB (513).

Phase (8): the bank (504) compares the data in stand-by in the respective DBs (512) and (513) and verifies its correctness with reference to the original payment operation arranged by (501) with Phase 1. In the event of an inconsistency, the bank (504) notifies the parties of the impossibility of making the payment and, if necessary, informs about the possible reasons.

Phase (9): in the event of a positive check, the bank (504) arranges the payment by forwarding it to the interbank network (506)

Phase (10): the interbank network (506) provides the various clearing and settlement functions and forwards the payment to the payee bank (507)

Phase (11): the payee bank (507) credits the sum as received from (506) on the current account (508) of the payee (510)

Fig. 6 - Process I and J - details the automated procedure for further recognition and certification of the Payee by the Payer who alternatively communicates either the numbers extracted from the telephone number or the numbers extracted from the IBAN number of the Payee to which he has ordered the transfer.

Function List

Phase (1): The Payer (601) by logging into Home banking on your Desktop (602) or alternatively using the app installed on your smartphone (602) prepares a wire transfer order for your bank (604) to be debited from your current account (603). In this phase (601) communicates the Payee header, the Payee IBAN, the amount to be paid, the reason for payment.

Phase (2): The bank (604) performs a formal check on the order just received and places said order in stand-by on the DB (612)

Phase (3): the bank (604) through its messaging server (614) based on the transfer order received from (601) responds to the device (602) by sending a message such as the following:

BANK 123XYZ - Bank transfer to M * B * € 200 for confirmation call 020808 followed by the last 4 digits of the IBAN of M * B *

or alternatively as another example below:

BANK 123XYZ - Bank transfer to M * B * € 200 for confirmation calls 020808 followed by the last 4 digits of M * B * mobile phone

and where in respect of privacy, M * B * stands for Mario Bianchi as payee (609).

Phase (4): the Payer (601) by means of (602) telephones the Pabx (611) of the bank (604) by following the GNR number with the CRO consisting of the last 4 digits of the IBAN (608) of the payee (609) or alternatively the last 4 digits of the mobile number of (610)

Phase (5): the bank (604) receives the call to its Pabx (611) from (602) but does not answer the call - it does not provide the ACK - but in the signaling flow of the same call it reads, at the interface connection with adequate equipment for reading the transmission protocols, the so-called INFO Element where, in it, the data / number of the caller CLI or Calling party number are contained - in this case the CLI of (602) and the data / the number of the called CLDn or Called party number - in this case the CLDn of the bank's PABX (604) which corresponds to the GNR (restricted numerical group), i.e. the radical of the number assigned to the Pabx (611) followed by the CRO communicated by (601) referable to the last 4 digits of the IBAN or alternatively to the last 4 digits of the mobile phone number (610) of the Payee (609).

Phase (6): The Pabx (611) discriminates on the CLDn entered by the Payer (601) the GNR number from the CRO and puts the CRO in the DB (613) on stand-by

Phase (7): the bank (604) compares the data in stand-by in the respective DBs (612) and (613) and verifies their correctness with reference to the original payment operation arranged by (601) with Phase 1. In the event of an inconsistency, the bank (604) notifies the parties of the impossibility of making the payment and, if necessary, informs about the possible reasons.

Phase (8): in the event of a positive check, the bank (604) arranges the payment by forwarding it to the interbank network (606)

Phase (9): the interbank network (606) provides the various clearing and settlement functions and forwards the payment to the payee bank (607)

Phase (10): the payee bank (607) credits the sum as received from (606) on the payee's current account (608) (610)

With reference to the previous description in Phase 12 of Figure 3 and Phase 3 of Figure 6, these functions depend on the choice of the logical unit of the bank that carries out the verification of the beneficiary of the transaction which can, at its discretion, carry out the choice of the findings deemed most suitable for the various cases in question.

Glossary

- 2G / 3G / 4G / 5G: cellular networks defined in the various standards for transmission speed and bandwidth capacity

- ACK: Acknowledge symbol as confirmation of receipt of a complete info - ACM: Active communication mode, NFC system for automated p2p connections - ANDROID: Operating system for mobile phones - GOOGLE

- BANK-NOTES®: Payment system based on real time interbank networks - BTS: Base tranceiver receiver

- Blockchain: chain of blocks (nodes) for transmission and related data recording - Biometric: unique and univocal personal feature

- CLI: caller identification number

- CLDn: identification number of the person called

- CRO: Operation reference code

- DSS1: Digital Subscriber Serve 1 - ISDN signaling

- DIGIT: In binary system the digits 0 or 1, usually a digit a digit of a number - ECMA: European Computer Manufacturers Association

- ETSI: European Telecommunications Standards Institute

- Geo Reference: Geographic positioning determined by cross lat. and long

- GNR SP: Telephony, restricted number group - pass-through selection

- GPS: Global positioning system

- HCE: Host card emulation

- IBAN: International Bank Account Number

- ICCID: Integrated Circuit Card ID

- IETF: Internet Engineering Task Force

- IMEI: International Mobile Equipment Identity

- Info Element: info regarding transmission data between telephone devices and data

- ISO: International Organization for Standardization

- ITU-T: International Telecommunication Union - Telecommunication Standardization - ITU-T E.164 - International standards relating to telephone numbering

- IVR: Interactive voice response

- JIFFY: Circuit for instant payments by SIA Spa

- LBS: Location Based Services

- L.I .: Lawful Interception

- Man in the middle: hacker attack on the transmission channel between payer and payee

- Man in the Browser: hacker attack via proxy virus placed on the payer's browser - Man in the App: hacker attack via proxy virus placed in the APP on the cell. of the payer - MY BANK: Circuit for instant payments by EBA Clearing

- NFC: Near field communication

- OCR: Optical character recognition

- OTP: On Time password

- PABX: Private branch exchange

- Payer: Paying party - PAOLO ROSSI

- Payee: Receiving party - MARIO BIANCHI

- Phone Provider: Telephone operator

- PIN: Personal identification code

- POS: Point of services

- QrCode: Quick response code

- Q. 769: Switching and signaling on SS7

- Q. 931: Switching and signaling on DSS1

- Random: random execution of a function

- SEPA: Single European Payment Area

- SCT Inst: SEPA Credit Transfer instant

- SIM: Subscriber Identity module

- SIP: Session Initiation Protocol

- SS7: Signaling system 7

- Satispay: Circuit for instant payments by ICCREA

- Pass-through selection: Management of incoming calls directly sent to the extension - TAG: Character or sequence of characters that acts as a field marker

- Triangulation: Operation performed by telephone operators to determine a point - Trojan banker: Computer virus to capture payment information

The verification and certification operations implemented through particular flows, as described, highlight a new system and relative method that is easy to implement, safe from any attacks and particularly economical.

For these reasons, the following claims are set forth

Claims (1)

CLAIMS 1. System, with increasing degrees of security, for carrying out electronic payments between a payer (301) and a recipient (309), the payer having its own counter current (303) at a financial institution (304) , the recipient having a current account (308) at another or the same financial institution (307), the system having the possibility of using, depending on the degree of security desired, all or part of the devices and systems indicated below and choosing, of the devices, the relative functions or capabilities of each of the same and, characterized by the fact of comprising: - a first device (302) intended to be used by the payer, said first device configurable to interact with -line remotely with a computer system of said first bank (304) through the first channel (317) and through the second channel (316); - a second device (310) intended to be used by the receiving subject, said second device configurable to be able to interact with the first bank (304) through the second channel (316); - a third responder device (311) intended to be used by the bank's computer system (304), said third device bearing a telephone number of the GNR SP type, said third device configurable, by installing a dedicated application software, in order to interact , by means of a second channel (316) with the first device (302) and with the second device (310), in order to receive comparison data from the devices (302) and (310) and to be able to process and forward the data to the respective DB (312) and (313) and consequently to the Bank's IT system (304); - a fourth messaging service emitter device (314) intended to be used by the bank's computer system (304), said fourth device configurable, by installing a dedicated application software, in order to interact, through the second channel (316) with the second device (310) and the first device (302); - a fifth device, database and storage (312) intended to be used by the bank's computer system (304), said fifth configurable device, by installing a dedicated application software, in order to interact with the responder (311), and with the system of control, comparison and verification of the consistency of the bank data (304); - a sixth data base and storage device (313) intended to be used by the bank's computer system (304), said sixth configurable device, by installing a dedicated application software, in order to interact with the responder system (311) and with the system for controlling, comparing and verifying the consistency of the bank's data (304); - a seventh device, the computer system or logical unit of the bank (304), configurable: to perform verification and authorization operations, regarding the correctness of the payment orders ordered by (301), to perform a comparison between data contained in the DBs ( 312) and DB (313), to perform random requests to the payer (301) regarding the values contained in certain positions in the IBAN of the recipient (308) to access the token table (305), to send request messages to equipment (302) and (310), to authorize the execution of payment requests and to forward them to the interbank network (306). wherein the first device (302) is configurable to send an order to the computer system of said first bank (304) for the transfer of funds from the current account (303) of the payer at said first bank (304) to the current account (308 ) of the receiving subject at said second bank (307); wherein the first device (302) is configurable to be able to call the responder system (311) on the second channel (316) and to send acknowledgment information; in which the first device (302) is configurable to access the TOKEN table (305) on the basis of the request of the logical unit of the bank (304) so as to determine the key to be communicated to the responder (311) of (304) in which the first device (302) can be configured to receive request messages directly from the bank (304) on channel (317) or indirectly by sending requests via server (314) on channel (316) and where (302) is configurable to respond to said messages to the responder (311) with acknowledgment information as requests on the second channel (316) in which the second device (310) is configurable to receive a request message from the bank (304) through messages sent via the server (314) on channel (316) and where (310) is configurable to reply to said message on the responder (311) with the acknowledgment information requested by the bank (304) on the second channel (316) in which the third device, responder system (311), is c configurable in order to be able to read and discriminate in the signaling relating to telephone flows arriving on the second channel (316), the acknowledgment information coming from the devices (302) and / or (310) in which the third device, the responder system (311) is configurable for send the discriminated acknowledgment information coming from the devices (310) and (302) and send them to the DB (313) in which the fourth device, messaging server (314), can be configured on the disposition of the logical unit (304) to send messages to obtain verification and response from the devices (302) and (310) in which the fifth device, database and storage (312), is configurable to receive and process the acknowledgment data coming from (304) in which the sixth device, database and storage (313), is configurable to receive and process the acknowledgment data from (311) in which the seventh device, bank logic unit (304), is configurable to order the sending of messages to the devices rati (302) and / or (310) via the messaging server (314) in which the seventh device, bank logic unit (304), can be configured to request from the device (302) the equivalent value of the IBAN digits (308 ) of the beneficiary (309), ordered a payment by (301), corresponding to the positions chosen randomly by the bank (304), in which the seventh device, bank logic unit (304), is configurable to access the Token table (305) to verify consistency with the IBAN data (308) of the beneficiary (309) as per key sent via responder (311) from the first device (302) in which the seventh device, bank logic unit (304), is configurable to execute comparison with the data present in the two databases (312) and (313) and can be configured to authorize, on the basis and consistency of the data received, the execution of the payment ordered by the paying party (301) in which the seventh device, the system computer scientist of the bank (304), can be configured for co compare the order received to the computer system from the first channel (317) with the acknowledgment data received on the second channel (316) by means of the telephone call of the device (302) directed to the answering system (311); wherein the seventh device, the computer system of the first bank (304), is configurable to compare the order received from the first channel (317) with the acknowledgment data received on the second channel (316) by means of the telephone call of (310) directed to the responder system (311) 2. Security system for the execution of electronic payments, according to claim 1, in which the first device (302), the second device (310) and the responder system (311) are configurable to exchange among them information using one or more of the following transmission technologies: ISDN, SIP, 2G, 3G, 4G, 5G and again NFC, RFID, Wi-Fi, TCP / IP, BarCode, QrCode, IrDA, Bluetooth. 3. Security system for the execution of electronic payments, according to one or more of the preceding claims, in which the device (302) of the paying party (301) can make use of QrCode, Barcode, and OCR systems to determine the data necessary for the compilation of the payment order to the bank (304) 4. Security system for the execution of electronic payments, according to one or more of the preceding claims, in which the responder system (311) is configurable to read and discriminate in the signaling of telephone termination flows the CLI - Calling Line Identification data, the CLDn - Called party number and in this, the CRO, the latter as data communicated as a string of numbers in sequence following the radical of the GNR SP 5 number. for the execution of electronic payments, according to one or more of the preceding claims, in which the logic unit / computer system of the bank (304) is configurable to verify the l IBAN code (308) of the beneficiary (309) correlating the CLI value of the device (310) with the IBAN number (308), these data communicated by the payer (301) during the payment order phase to the bank (304 ). 6. Security system for the execution of electronic payments, according to one or more of the preceding claims, in which the logical unit / computer system of the bank (304) is configurable to verify the IBAN code (303) of the user ( 301) correlating the value of the CLI with the IBAN number assigned by the bank (304) to the user (301) during the customer registration phase; 7. Security system for the execution of electronic payments, according to one or more of the preceding claims, in which the computer systems of the bank (304) are equipped with automated answer and call systems (311) suitably equipped with dedicated software and in which, said devices, are configured and programmable to read and manage the CLI and CLDn, and in which, said dedicated software, is programmed to discriminate in the CLDn, as read, the various CROs generated by (302) (310) through calls made on the canals (316). 8. Security system for carrying out electronic payments, according to one or more of the preceding claims, in which the first device (302) and the second device (310) are respectively: a POS, a workstation, a personal computer, a desktop, a laptop, a smartphone, a tablet, or a wearable and where these devices can be equipped with a display, video camera, and can operate on both fixed and mobile networks 9. Security system for making electronic payments, according to one or more of the preceding claims, in which the messaging systems (314) of the bank (304) can manage and generate SMS messages, emails, chats. 10. Method, with increasing degrees of security, for carrying out electronic payments between a payer (301) and a recipient (309), the payer having its own counter current (303) at a financial institution (304), the receiving subject having available his own current account (308) with another or the same financial institution (307), the system having the possibility of using, depending on the degree of security desired, all or part of the devices and systems indicated below and choosing, of the devices, the relative functions or capabilities of each of the same and, characterized by the fact of including: - providing a first device (302) intended to be used by the payer, said first device configurable to interact with -line remotely with a computer system of said first bank (304) through the first channel (317) and through the second channel (316); - providing a second device (310) intended to be used by the receiving subject, said second device configurable to be able to interact with the first bank (304) through the second channel (316); - provide a third responder device (311) intended to be used by the bank's computer system (304), said third device bearing a telephone number of the GNR SP type, said third device configurable, by installing a dedicated application software, in order to interact, through a second channel (316) with the first device (302) and with the second device (310), to be able to receive comparison data from devices (302) and (310) and to be able to process and forward the data to respective DBs (312) and (313) and consequently to the Bank's IT system (304); - provide a fourth messaging service emitter device (314) intended to be used by the bank's computer system (304), said fourth configurable device, by installing a dedicated application software, to be able to interact, through the second channel (316) with the second device (310) and the first device (302); - provide a fifth device, database and storage (312) intended to be used by the bank's computer system (304), said fifth configurable device, by installing a dedicated application software, in order to interact with the responder (311), and with the system of control, comparison and verification of the consistency of the bank's data (304); - provide a sixth data base and storage device (313) intended to be used by the bank's computer system (304), said sixth configurable device, by installing a dedicated application software, in order to interact with the responder system (311) and with the system of control, comparison and verification of the consistency of the bank data (304); - provide a seventh device, the computer system or logical unit of the bank (304), configurable: to perform verification and authorization operations, regarding the correctness of the payment orders ordered by (301), to perform a comparison between data contained in the DBs (312) and DB (313), to execute random requests to the payer (301) regarding the values contained in certain positions in the IBAN of the receiving subject (308) to perform accesses to the token table (305), to send request messages to the apparatuses (302) and (310), to authorize the execution of payment requests and to forward them to the interbank network (306). wherein the first device (302) is configurable to send an order to the computer system of said first bank (304) for the transfer of funds from the current account (303) of the payer at said first bank (304) to the current account (308 ) of the receiving subject at said second bank (307); wherein the first device (302) is configurable to be able to call the responder system (311) on the second channel (316) and to send acknowledgment information; in which the first device (302) is configurable to access the TOKEN table (305) on the basis of the request of the logical unit of the bank (304) so as to determine the key to be communicated to the responder (311) of (304) in which the first device (302) can be configured to receive request messages directly from the bank (304) on channel (317) or indirectly by sending requests via server (314) on channel (316) and where (302) is configurable to respond to said messages to the responder (311) with acknowledgment information as requests on the second channel (316) in which the second device (310) is configurable to receive a request message from the bank (304) through messages sent via the server (314) on channel (316) and where (310) is configurable to reply to said message on the responder (311) with the acknowledgment information requested by the bank (304) on the second channel (316) in which the third device, responder system (311), is c configurable in order to be able to read and discriminate in the signaling relating to telephone flows arriving on the second channel (316), the acknowledgment information coming from the devices (302) and / or (310) in which the third device, the responder system (311) is configurable for send the discriminated acknowledgment information coming from the devices (310) and (302) and send them to the DB (313) in which the fourth device, messaging server (314), can be configured on the disposition of the logical unit (304) to send messages to obtain verification and response from the devices (302) and (310) in which the fifth device, database and storage (312), is configurable to receive and process the acknowledgment data coming from (304) in which the sixth device, database and storage (313), is configurable to receive and process the acknowledgment data from (311) in which the seventh device, bank logic unit (304), is configurable to order the sending of messages to the devices rati (302) and / or (310) via the messaging server (314) in which the seventh device, bank logic unit (304), can be configured to request from the device (302) the equivalent value of the IBAN digits (308 ) of the beneficiary (309), ordered a payment by (301), corresponding to the positions chosen randomly by the bank (304), in which the seventh device, bank logic unit (304), is configurable to access the Token table (305) to verify consistency with the IBAN data (308) of the beneficiary (309) as per key sent via responder (311) from the first device (302) in which the seventh device, bank logic unit (304), is configurable to execute comparison with the data present in the two databases (312) and (313) and can be configured to authorize, on the basis and consistency of the data received, the execution of the payment ordered by the paying party (301) in which the seventh device, the system computer scientist of the bank (304), can be configured for co compare the order received to the computer system from the first channel (317) with the acknowledgment data received on the second channel (316) by means of the telephone call of the device (302) directed to the answering system (311); wherein the seventh device, the computer system of the first bank (304), is configurable to compare the order received from the first channel (317) with the acknowledgment data received on the second channel (316) by means of the telephone call of (310) direct to responder system (311)