CN108780547B - Proxy device for representing multiple certificates - Google Patents

Abstract

A payment device and a system and method for securely managing financial transactions using the same are provided. In one embodiment, a portable proxy device includes a memory configured to store a plurality of credentials. Each of the plurality of certificates belongs to one of a financial certificate, an identification certificate, or a contract certificate. The portable agent device also includes at least one interface, wherein each of the at least one interface is configured to transmit one of the plurality of credentials to the external device to perform one of a financial function, an identification function, or a contract function.

Description

Proxy device for representing multiple certificates

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of US Provisional Application US62/283769, filed September 10, 2015, the entire disclosure of which is incorporated herein by reference.

technical field

The present disclosure relates generally to financial services, and more particularly to payment devices and systems for settling financial transactions.

Background technique

In the late 1940s, the United States introduced plastic payment cards such as credit cards as a way for the bank's most trusted customers to pay for meals and travel without carrying large amounts of cash. Since then, thousands of banks have issued billions of payment cards.

However, many types of illegal activities pose a threat to the security of traditional payment card systems. Identity theft, impersonation, fraud, unauthorized account access, and other illegal activities can compromise system integrity. Traditional payment cards and the networks used to authorize and settle card transactions are vulnerable to widespread attack by identity thieves and other criminals. A major form of payment account fraud is the unauthorized use of payment account details while conducting electronic commerce. Another major form of payment account fraud is the production of counterfeit cards and use at merchants' point-of-sale (POS) devices. These forms of fraud are inherent in the way the payment cards themselves are produced. Specifically, credit card numbers and other payment account details printed or embossed on traditional plastic payment cards can be easily copied or stolen. In addition, the magnetic strip of the payment card can be counterfeited. In fact, losses to banks, merchants and consumers from payment card fraud are rapidly increasing. Payment card fraud costs the industry nearly $20 billion annually.

These practices are a source of major financial risk for banks and payment brands, and in an effort to combat counterfeiting and misappropriation fraud, major card issuing networks have adopted new technology to ensure that only legitimate cards are used at physical points of sale. These technologies, developed by the Payment Card Industry and the Issuing Networks Consortium (EMVCo), add tamper-resistant computer microchips with secure storage and computing power to plastic cards. EMVCo is the payments industry consortium named after EuroPay, MasterCard and Visa, who were the original founders of the group but now also includes AmericanExpress, Discover, JCB and UnionPay as equity partners.

The microchip confidentially stores the information and procedures needed to generate a unique cryptographic signature when making a transaction at the merchant's POS. The calculation process is performed securely and confidentially inside the embedded microchip at each transaction, and the result is passed along with the payment account data through the existing payment network to the issuing bank, where it is performed using the same information stored in the card. verify. The stored information is never disclosed by the issuing agency and cannot be extracted from the microchip by any practical means. Such microchip embedded cards provide a one-time code for each card transaction performed at the physical point of sale. If all merchants comply with this new mechanism, the risk of counterfeit cards being created by theft of account data is greatly eliminated.

Another way issuers are trying to combat fraud is to offer cards with near field communication (NFC) components. An NFC component-enabled card allows the user to tap or swipe the card within about 10 centimeters of the NFC reader.

However, microchip embedded cards (also known as EMV cards or smart cards) as well as NFC-enabled cards must also work in environments that have not yet adopted the new standard. Many merchants have not yet adopted EMV-enabled terminals that can activate microchip cards and read passwords, or NFC readers that can read wireless communication signals. To ensure payment cards are universally accepted, issuers place a traditional magnetic stripe on the back of the card.

In addition, in order to enable e-commerce and telephone transactions, issuers also set up payment account numbers printed on cards and/or embossed on plastic. Therefore, not only the microchip and the NFC component can be used for financial transactions, the magnetic strip can also be used for financial transactions using the POS swipe method or the account number can also be used for telephone or Internet transactions. The method by which the card communicates account information to the merchant terminal is called a schema. In other words, the microchip card can be used in at least four different financial transaction modes, including, for example, a magnetic stripe swipe mode, various modes using an EMV chip, an NFC mode, and a manual card number entry mode. Microchips may also enable other modes, which is one reason there may be more than four different modes of financial transactions.

A thief who encounters one of these new EMV or NFC payment cards and has physical control of the card even for a short period of time can easily steal sensitive payment account data without having to think about the embedded chip or NFC components. This can be done by reading the payment data from the magnetic strip to prepare a counterfeit card. Thieves can also steal data for fraudulent e-commerce by taking a picture of the card to capture the card number. It should be noted that neither the magnetic stripe data nor the print data is protected by digital security means such as cryptography. The leaked data could then be used at less secure retailers that have not yet adopted an EMV system, or thieves could go online to conduct e-commerce transactions.

Therefore, there is a need for more secure payment cards. To address the above problems and improve customer satisfaction and control over the payment card experience, the present invention introduces several innovative elements to payment cards and financial networks, as well as financial transaction authorization and settlement.

SUMMARY OF THE INVENTION

The present disclosure describes payment devices and related systems and methods for securely managing financial transactions using the payment devices. Payment devices may take the form of, for example, portable proxy devices, plastic payment cards, virtual cards, wearable commerce devices, one or more components embedded in a mobile device, an application running on a mobile device or computer, and other forms of payment certificates . According to one embodiment, the portable proxy device includes a memory configured to store a plurality of credentials. Each of the plurality of certificates is related to one of a financial certificate, an identity certificate or a contract certificate. The portable proxy device also includes at least one interface, wherein each of the interfaces is configured to communicate one of the plurality of credentials with an external device to perform one of a financial function, an identification function, or a contract function.

According to another embodiment, a system includes a point-of-sale (POS) device configured to obtain at least one certificate from a mobile agent device, each of the at least one certificate being associated with a financial certificate, an identification certificate, or a contract One of the certificates is related. The system also includes a payment processor configured to receive at least one credential obtained from the mobile agent device and to perform at least one of a financial function, an identification function, or a contract function.

The various embodiments described in this disclosure may include additional systems, methods, features, and advantages that may not need to be explicitly disclosed herein, but will be apparent to those of ordinary skill in the art upon review of the following detailed description and accompanying drawings. will be obvious. It is intended that all such systems, methods, features and advantages be included within this disclosure and protected by the accompanying claims.

Description of drawings

The features and components of the following figures are illustrated to emphasize the general principles of the disclosure and are not necessarily drawn to scale. For consistency and clarity, corresponding features and components have been designated throughout the drawings by matching reference numerals.

FIG. 1 is a block diagram illustrating a payment system according to various embodiments of the present disclosure.

2A and 2B illustrate a front view and a rear view, respectively, of a first payment device according to various embodiments of the present disclosure.

3A and 3B illustrate a front view and a rear view, respectively, of a second payment device according to various embodiments of the present disclosure.

FIG. 4 is a block diagram illustrating the account association apparatus shown in FIG. 1 according to various embodiments of the present disclosure.

5 is a block diagram illustrating the user account module shown in FIG. 4 in accordance with various embodiments of the present disclosure.

FIG. 6 is a diagram illustrating a proxy device representing a plurality of cards according to various embodiments of the present disclosure.

7 is a diagram illustrating a mobile agent device representing a plurality of devices in accordance with various embodiments of the present disclosure.

8 is a flow diagram illustrating the general use of the proxy device of FIGS. 6 and 7 to allow optional credentials in accordance with various embodiments of the present disclosure.

9 is a flow diagram illustrating the general use of the proxy device of FIGS. 6 and 7 in default mode according to various embodiments of the present disclosure.

FIG. 10 is a flowchart illustrating a detailed method of operation of the payment system 10 of FIG. 1 according to various embodiments of the present disclosure.

FIG. 11 is a flowchart illustrating another detailed method of operation of the payment system 10 of FIG. 1 according to various embodiments of the present disclosure.

FIG. 12 is a flowchart illustrating a financial information transmission method of a financial transaction according to various embodiments of the present disclosure.

13 is a flowchart illustrating a method of operation of a tokenization process for user registration according to various embodiments of the present disclosure.

14 is a flowchart illustrating a method of operation of a tokenization process for registration according to various embodiments of the present disclosure.

Figure 15 illustrates a transaction flow architecture according to various embodiments of the present disclosure.

16-20 are flowcharts illustrating an overview of a transaction flow process in accordance with various embodiments of the present disclosure.

Detailed ways

The present invention relates to payment devices such as, for example, plastic payment cards, virtual cards, wearable business devices, components embedded in mobile devices, applications running on mobile devices or computers, and other payment credentials. The present invention also relates to systems and methods for conducting financial transactions using payment devices. The present invention may include commercially viable computing services, mobile applications and websites, and may be implemented with issuers using payment cards or other payment devices as described herein. The present invention introduces several novel elements that can be employed by existing devices and valid certificate issuing authorities to combat various forms of fraud. The term "valid credential" as used in this document means a valid funds transfer instrument, which may include, but is not limited to, a credit card, charge card, direct deposit account, savings account, checking account, loyalty card, gift card or other card or device.

The present invention includes a multimodal payment device that can be used in various modes for different types of financial transactions. For example, the payment devices described herein may include multiple modes for completing transactions. Some modes may include those involving microchips embedded in the device, those involving Near Field Communication (NFC) components, those involving magnetic stripes, those involving entering device numbers and card verification values (CVVs) in online transactions mode, and/or other modes. The present invention includes novel fraud reduction features, mobile phone applications and accompanying web sites to control the novel fraud reduction functions. In addition, computing services are available in both online and retailer authorization and settlement network services.

The current issuance practice for payment devices is to include the user's single primary account number (PAN) details in all of the various modes of the payment device (ie including magnetic stripe, EMV chip, NFC, etc.), which directly correspond to the user's actual valid credentials. However, by using an alternate account number or token in place of the primary account number (PAN), as described in this disclosure, account linking means can be inserted between the merchant and the issuing bank to complement the security of the transaction, or by the issuing bank as a Part of processing the payment invokes the account linking means. The payment device system described herein securely replaces the user's PAN details in the network prior to transaction authentication and settlement. In this way, leakage of the user's PAN details to the merchant is prevented.

The present invention uses multiple sets of distinct, anonymous and unpredictable alternate account details for each payment device and/or each mode of each payment device. In the example of a physical payment card, one set of alternate account details may be associated with one or more modes of the EMV chip, another set may be associated with another mode of the EMV chip, and another set of alternate account details may be associated with the NFC component, Another set is for magnetic stripes, another set is used in e-commerce, and another set is used for manual entry. Using multiple sets of different alternate account details can prevent cross-modal payment fraud.

Current practice is to include the same PAN in an EMV chip, which is contained in a magnetic strip and printed on the device. Financial transactions are accepted when any of a number of patterns are present, making cross-modal fraud possible. For example, thieves may intercept EMV device details and generate counterfeit magnetic strip devices. Additionally, thieves may use device data readers to collect both EMV and magnetic stripe account details and perform unauthorized e-commerce transactions. However, the present invention is not limited to the same PAN being used for all modes. Instead, the present invention uses multiple sets of different alternate account details corresponding to multiple valid credentials, where each alternate account may be associated with a different schema. In this way, cross-modal payment fraud can be prevented.

It should be noted that the payment devices described in this disclosure may be implemented as credit cards, debit cards, virtual cards, wearable devices, Internet of Things (IoT) devices, components and/or applications embedded in mobile devices, and/or Other financial certificates. In other embodiments, the payment devices described in this disclosure may be applied to non-payment devices used in environments other than business. For example, non-payment devices (eg, loyalty cards, mobile devices, and other non-financial credentials) may be applied to other functions as proxy credentials for electronically authenticating identities, such as for health insurance purposes, driver's license purposes, etc., to access Secure location, provide user image recognition, and other uses. Additionally, valid credentials that may be associated with alternate account details may be payment and/or non-payment credentials, such as membership credentials, health insurance credentials, and other financial or non-financial credentials.

1 is a block diagram illustrating one embodiment of a payment system 10 in which an issuer 28 issues a payment device, such as a credit or debit card, to a user. In other embodiments, the user may use other types of proxy credentials than payment cards, such as mobile devices. According to the embodiment of FIG. 1, a payment system 10 includes a public network 12, one or more user devices 14, one or more merchant terminals 16, one or more wireless communication antennas 18, one or more mobile devices 20, and an account Associated device 24 .

The term "merchant terminal" is used to describe a physical terminal, website or other device that provides functionality for the merchant who initiates the payment. Merchant terminals can be embedded into POS devices and can be "virtual" as in commerce website processing. Additionally, a merchant terminal may be a backend device that does not involve devices, cards, customers, merchants, or goods, such as when initiating recurring payments for services, "merchant terminals" may represent POS devices, merchant online systems, and merchant owned/controlled Other mechanisms to carry out various buying patterns. Merchant terminals may include any merchant system that uses one or more types of technology (eg, EMV chip, magnetic strip, NFC, e-commerce, etc.) for different payment modes.

Network 12 may include a wide area network, the Internet, a private network, and/or other publicly accessible networks. Also, the network 12 may include local area networks associated with various merchants. The network 12 may also communicate with one or more cellular networks connected to the antenna 18 .

User devices 14, merchant terminals 16, and antennas 18 may be connected to network 12 through one or more wired or wireless connections to enable electronic communication between the various components. The wireless communication antenna 18 may include one or more cellular towers, orbiting satellites, or other wireless communication hubs for communicating with the mobile device 20 .

Account linking device 24 may be a server, a web server, software running on a server, a hardware device, or any suitable intermediate computing device for providing various transaction services. Account linking means 24 is also connected to a network 26, which is also connected to one or more issuers 28 and one or more databases 30 via wired or wireless connection means. The network 26 may be a private network, a local area network, a virtual private network (VPN), or a public network with a high level of encryption. Account linking device 24 may be configured to store information in database 30 that directs one or more alternate accounts to real accounts owned by users or customers of issuer 28 .

During a purchase operation, the user to whom the payment device has been issued can use the payment device to pay for goods or services. The payment device may be presented to the merchant at one of the merchant terminals 16 . It should be noted that multiple merchant terminals 16 may be associated with the same merchant to obtain account information through various modes. In effect, multiple merchant terminals 16 may be associated with a single device used by the merchant to obtain information at a single POS device. The POS device may obtain information from the payment device through a first mode utilizing a microchip embedded in the device or through other modes, which may involve the use of an NFC component or a magnetic strip on the device. In other transactions, such as online or telephone transactions, the device number printed and/or imprinted on the device may be entered electronically or by the merchant's order taking representative.

According to alternative embodiments, payment system 10 may alternatively be configured as a system for performing non-payment actions. Instead of performing various functions related to financial accounts as disclosed herein, non-payment systems may process other types of credentials from entities other than issuers.

The account association means 24 uses the database 30 to associate any alternate account data values to the details of the user's valid credential details. Any alternate account data values and valid credential details may be provided by the user when logging into the services provided by the account linking device 24 . In one embodiment, the user may use a mobile application on one of the mobile devices 20 at any time or use a web service provided by one of the user devices 14 via the account association device 24 to change the valid credential details associated with the alternate account, the user Device 14 may be a conventional computer or web browser. Account association means 24 enables a plurality of valid credentials, which may be financial or non-financial credentials, associated with a plurality of alternate accounts. In one embodiment, account associating means 24 associates valid credentials from issuer 28 with a plurality of alternate accounts. In one embodiment, account associating means 24 associates valid credentials from issuers 28 and other financial or non-financial institutions with a plurality of alternate accounts.

The account linking device 24 is deployed into the payment system 10 such that all transactions presented by the merchant through one of the merchant terminals 16 are received by the account linking device 24 for one of the multiple alternate accounts represented on each device authorized. Account association device 24 associates the plurality of alternate accounts with one or more user valid credentials using a customizable rules engine that is sensitive to one or more facts including, but not limited to, current transaction data. Current transaction data may include, but is not limited to, for example, merchant category codes, merchant IDs, transaction volumes, alternate account numbers, service codes, device security codes, and the like.

Account linking device 24 may also access data through database 30 including, but not limited to, previous transactions presented for a particular alternate account, previous transactions presented for another alternate account associated with the same user, other transactions for the same merchant or merchant location The user's previous transactions, the geographic location of the user's primary mobile phone at the time of the transaction, are displayed. The geographic location can be determined by, for example, the Global Positioning System (GPS), radios such as Wi-Fi ^™ , Bluetooth ^™ , Bluetooth Low Energy Beacons, Zigbee ^™ , Z-wave ^™ , or any combination of these and other location-sensitive factors distance of the signal. Alternative accounts can be associated with valid credentials, unless otherwise associated, have no balance or established credit of their own, and cannot be used to settle any transactions.

The payment system 10 may be used to provide security for the use of payment devices. The payment system 10 may include a first merchant terminal 16 connected to the public network 12, wherein the first merchant terminal 16 is configured to obtain details of the first alternate account from a first set of information associated with a payment device owned by the user. The payment system 10 may include a second merchant terminal 16 connected to the public network 12, wherein the second merchant terminal 16 is configured to obtain details of the second alternate account from a second set of information associated with the payment device. In this embodiment, the payment system 10 also includes account linking means 24 connected to the public network 12 . The account associating means 24 is configured to receive details of the first and second alternate accounts from the first and second merchant terminals 16, respectively. The account association means 24 is further configured to associate the first and second alternate accounts with valid credentials belonging to the user. The account linking device 24 also manages financial transactions between the issuer 28 and the first and second merchant terminals 16, from which the user maintains valid credentials. Furthermore, it should be noted that the first set of information is preferably different from the second set of information.

The payment system 10 may also include a third merchant terminal 16 connected to the public network 12, wherein the third merchant terminal 16 may be configured to obtain details of the third alternate account from a third and preferably a different set of information associated with the payment device . In some embodiments, a first set of information is obtained from a microchip on the payment device, a second set of information is obtained from an NFC component embedded in the payment device, a third set of information is obtained from a magnetic strip on the payment device, and a fourth set of information is obtained from a magnetic stripe on the payment device. The group information is obtained from the card number printed and/or embossed on the payment device. The first, second, third, fourth and other sets of information may be generated by the issuing agency. Some of these group information can be manually entered into the merchant terminal.

Alternative embodiments include payment system 10 wherein the payment device does not have a printed and/or embossed account number. Also, the payment device may not have a magnetic strip or other pattern. In this case, the user may use the payment device only at the merchant terminal, using only the microchip and/or NFC components, or the remaining modes on the device.

Account details for different groups can be communicated to the user for online or telephone transactions. Details of the different groups may be mailed, emailed, or messaged to the user by computer (eg, user device 14 ) and/or via mobile device 20 .

In some embodiments, the mobile device 20 associated with the user may be incorporated into the payment system 10 . One of the merchant terminals 16 may be configured as an online merchant device that conducts online transactions, and the mobile device 20 may be configured to store, retrieve, or calculate a dynamic card verification value (d-CVV) generated from the account association device 24, which is Sent to or manually entered into an online merchant device. In some cases, one or more merchant terminals 16 may be embedded within a point-of-sale (POS) device.

User device 14 associated with the user is configured to enable the user to manage alternate accounts and valid credentials via account association device 24 . The account linking device 24 is configured to enable the user to enter registration information, monitor the activity of the alternate account, enable and disable one or more modes of transaction with the payment device, alert the police if the payment device is lost or stolen, and provide communication with various accounts. information about a valid certificate. For example, account association device 24 may provide a website that includes one or more web pages, enabling a user to browse the website using user device 14 .

2A and 2B illustrate a first type of payment device 36 in accordance with various embodiments of the present invention. FIG. 2A shows the front side 38 of the payment device 36 and FIG. 2B shows the back side 40 of the payment device 36 . The payment device 36 may include the name 42 of the issuer 28 , the microchip 44 , the device number 46 , the customer name 48 and the expiration date 50 on the front face 38 thereof. In some embodiments, the device number 46 may be embossed on the payment device 36 . Additionally, the back 40 of the payment device 36 may include a magnetic strip 52 , a signature box 54 and a card verification value (CVV) 56 . Payment device 36 may further include an NFC component, possibly embedded under the surface of payment device 36, for enabling contactless transactions.

In one embodiment, payment device 36 may be a plastic EMV microchip card issued by the issuing bank according to the issuing rules of one of several global branded payment networks. Payment device 36 includes configuration and personalization so that it can be used at any EMV enabled merchant POS.

However, the account details contained in the microchip 44 or other schema are not account details for the primary account number, but rather arbitrary values generated by the issuer. Account details may be referred to herein as "alternative account details". Alternate account details are used as a substitute for a valid certificate, but do not identify any specific user. Rather, it refers to an alternate account generated by the issuer, but not associated with any specific valid certificate.

In the embodiment of Figure 2, microchip 44 and magnetic strip 52 contain different payment account numbers, expiration dates, and other token account details for two different alternate accounts. In short, the microchip 44 and the magnetic strip 52 appear to represent completely different payment accounts. A transaction performed at a merchant that supports EMV using the microchip 44 will contain different account details than a transaction performed at a merchant using the magnetic strip 52 on the same device 36 . Additionally, NFC transactions can use different payment account details than EMV enabled mode and magnetic stripe mode.

In one embodiment, issuer 28 provides customers with alternative account details for use in electronic commerce and telecommerce transactions, such that the details are different from the alternative account details of microchip 44 or magnetic strip 52 . It will be appreciated that facsimile, electronic mail and other forms of electronic and telephone communication may also be used. It will also be appreciated that alternate account details may be recorded on the mail order form for transactions made by mail. Depending on the embodiment, the e-commerce alternative account details may not be printed or embossed on the payment device 36 but provided to the user separately, or may also be printed or embossed on the payment device.

3A and 3B illustrate a second payment device 60 according to various embodiments of the present invention. FIG. 3A shows the front 62 of the payment device 60 and FIG. 3B shows the back 64 of the payment device 60 . The payment device 60 may include the name 66 of the issuer and a microchip 68 on the front face 62 thereof. It should be noted that payment device 60 does not have the device number and user name that would normally appear on conventional payment devices. The back 64 of the payment device 60 may be blank, or may simply include the name and address of the issuer. Thus the backside 64 does not have the traditional magnetic stripe and CVV numbering. Payment device 60 does not have pre-printed account numbers, embossed account data, expiration data, user names, or other account data. By making the device anonymous and not including a human-readable account number, account data can be prevented from being easily stolen from the front and back of the device.

Currently, Visa ^™ and MasterCard ^™ include provisions for cards and other devices issued under their franchise agreements that require the user's name and account number to be displayed on the device. Therefore, the embodiment of Figure 3 does not follow these current rules. Nonetheless, the payment device 60 of the present invention can be carried openly without risk of loss or theft, since user names and account numbers are not visually retrievable. For online, mail order, telephone and similar transactions, a separate device or electronic file can be securely stored in the user's home.

In some embodiments, the payment devices 36, 60 may be formed from a plastic substrate ("card"). The first component (eg, microchip 44 ) may be incorporated into the plastic substrate on the card shown in FIGS. 2 and 3 . The first component may be configured to provide details of the first alternate account associated with the user's valid credentials. The payment card 36 of FIG. 2 may also include additional components incorporated into the plastic substrate. The add-on is configured to provide details of other alternate accounts associated with the user's valid credentials. The first surrogate account includes details that are different from the details of the second surrogate account and are also different from all other surrogate accounts. At least one of the first, second or other alternate accounts is provided to the merchant (eg, using the merchant terminal 16) to conduct financial transactions with the merchant.

The merchant is configured to communicate at least one alternate account detail to the account association device 24 via the network 12 . The account linking means 24 is configured to associate at least one alternate account with one of the user's valid credentials, and wherein the account linking means 24 is further configured to manage the issuer 28 associated with the user's primary financial account and the merchant terminal associated with the merchant Financial transactions between 16.

According to some embodiments, the payment device 36 of FIG. 2 may further include other components (eg, device number 46 ) incorporated into the plastic substrate. The device number can be printed and/or embossed on the plastic substrate. In alternate embodiments, the payment device (eg, payment card 60) may lack at least one of a printed or embossed account number, a magnetic stripe, and/or other patterns.

Details of the first, second and other alternate accounts may be read from the first, second and additional components by a point of sale (POS) device such as the merchant terminal 16 . To conduct financial transactions, some embodiments may include the use of a mobile device 20 associated with the user.

FIG. 4 is a block diagram illustrating one embodiment of the account linking device 24 shown in FIG. 1 . In the embodiment of FIG. 4 , the account association device 24 includes a security module 74 , one or more web pages 76 , a user account module 78 , one or more web interfaces 80 , and a transaction authentication module 82 . The one or more network interfaces 80 are configured to enable communication over the first public network 12 and also enable communication over the network 26 . The user account module 78 allows a user or customer to perform a number of different actions related to the financial account and how the payment devices 36, 60 are used. The user account module 78 is described in more detail below with reference to FIG. 5 .

The security module 74 may include a random number generator for generating a temporary dynamic card verification value (d-CVV). The d-CVV can be transmitted to the mobile device. In turn, the security module 74 may include an encryption engine for encrypting data transmitted over the public network 12 . Account linking device 24 may be configured as a web server that allows one or more users to access information from web page 76 and establish a secure connection for the transfer of sensitive data (eg, user information, device numbers, etc.). The transaction authentication module 82 is configured to authenticate financial transactions using the payment devices 36 , 60 .

In one embodiment, the token account details are protected by encryption using an encryption key that may be provided by the security module 74 . In one embodiment, the encryption key is derived from a user-created password. Conversely, in another embodiment, the encryption key may rely on other data including, but not limited to, the identity of the mobile device 20, the user identification number known to the security module 74 of the account association device 24, the country in which the user registered for the computing service , a master key controlled by the user's biometric authentication, such as a fingerprint, iris scan, facial or voice recognition, or a biorhythm pattern that matches one or more body rhythms including, but not limited to, pulse rate, epidermal conductivity, Iris size, blink rate, EEG, ECG, or other factors considered independently or in combination as individual biomarkers.

Ordinary plastic cards can have a separate three- or four-digit CVV printed on the back or front of the card. E-commerce sites now often require this value to ensure that the user owns the card. But since the CVV is a short number printed on the card, it can easily be stolen along with account data. Thus, this form of theft can be prevented using a dynamic CVV (d-CVV) that can be generated by the security module 74 at the time of the transaction and that is only applicable to one transaction. In some embodiments, the generated d-CVV is not used for only one transaction, but may be applied to multiple transactions associated with a particular merchant, or may be used multiple times based on other criteria, such as a certain date range, week days, business area codes, purchase categories, etc. According to some embodiments, the mobile application running on the mobile device 20 associated with the user may be configured to retrieve the d-CVV on demand. In another embodiment, a mobile application running on the mobile device 20 associated with the user may be configured to generate the d-CVV on demand. Alternatively, a website provided by account linking device 24 may be used when mobile device 20 is unavailable. Therefore, in this case, the account linking device 24 may generate the d-CVV.

In addition to being used during financial transactions, the payment system 10 may alternatively be used for non-payment purposes. For example, payment system 10 may be used to replace certain forms of identifiers with tokens or alternative identifiers. These identifiers may include social security numbers (in the United States), public health identification numbers, membership programs, other forms of account numbers, where using real numbers may present a risk of compromise, identity theft, or other fraud.

Account linking device 24 may also find applications to provide limited transactional access to protected sets of records, such as medical record requests, laboratory results, credit inquiries, professional licenses, commercial licenses, and other forms of identification using government or corporate issued accounts. Relying Party Inquiries.

Payment system 10 may also be used for some non-payment-purpose transactions, including driver's licenses, border control documents, building and resource access cards, and gift cards. In this embodiment, the payment device 36, 60 may use one or more modes of non-payment usage, while still using one or more modes of payment transactions that use separate alternate account details for the different modes.

In some embodiments, the account association device 24 may include at least one network interface 80 configured to communicate with the plurality of merchant terminals 16 via the first public network 12 and with the issuer 28 via the network 26 . For example, the issuer 28 may be a bank that issues the payment devices 36, 60 to users. The account association device 24 may also include a transaction authentication module 82 configured to, based on the first set of details obtained by the first merchant terminal of the first alternate account associated with the user-owned payment device 36, 60, for A first merchant terminal of the plurality of merchant terminals 16 authenticates the first financial transaction. The transaction authentication module 82 may be further configured to be a second merchant of the plurality of merchant terminals 16 based on a second different set of details obtained by a second merchant terminal of a second alternate account associated with the user-owned payment device 36 , 60 The terminal authenticates the second financial transaction.

Transaction authentication module 82 may be further configured to determine whether the alternate account corresponds to a valid user credential. The transaction authentication module 82 may be further configured to determine whether the received alternate account details correspond to alternate account details for the intended mode of use of the payment device. The transaction authentication module 82 is further configured to manage financial transactions between the issuer 28 and the first and second merchant terminals 16 . The transaction authentication module 82 is further configured to obtain other group details based on other merchant terminals of other alternate accounts associated with the primary account of the payment device 36 , 60 owned by the user, to authenticate other financial transactions for other merchant terminals of the plurality of merchant terminals 16 . The first set of details may be obtained from the microchip 44 on the payment device 36, 60, the second set of details may be obtained from the magnetic strip 52 on the payment device 36, and the third set of details may be obtained from printing and/or printing on the payment device 36 Imprinted account number 46.

Network interface 80 may be further configured to communicate with a remote device (eg, user device 14 or mobile device 20 ) associated with the user via network 12 . The network interface 80 may be further configured to receive instructions from the remote devices 14, 20 to enable the user to manage a master account associated with the payment device 36, 60, wherein managing the master account includes at least one of: entering registration information 86, monitoring the master account activities 94, enable and disable one or more modes of transactions through the payment device 90, report that the payment device has been lost or stolen 92, and provide information 88 related to the first and second alternate accounts.

FIG. 5 is a block diagram illustrating one embodiment of the user account module 78 shown in FIG. 4 . In this embodiment, the user account module 78 includes a registration module 86 , a provisioning module 88 , an enabling module 90 , a reporting module 92 and a monitoring module 94 . The user may access the user account module 78 using a mobile application running on the user's mobile device 20 or by accessing a website provided by the account association device 24 using the user's user device 14 .

The user account module 78 enables the user to create and manage rules that the account association device 24 executes on behalf of the user. Such rules may be sensitive to one or more facts known to the user, including, but not limited to, the payment value, the merchant ID, the local time and date encoded in the transaction message, the relationship between the merchant's registered location at the time of the transaction and the geographic location of the user's mobile device. distance, the local currency of the transaction, the country in which the transaction was initiated, the country in which the merchant was established, whether the transaction appears as a magnetic stripe transaction, EMV transaction, or an e-commerce, telephone, or mail order transaction, and user authentication methods such as the following One or more of, but not limited to, entering a personal identification number (PIN) code into a merchant POS terminal, signing a receipt, entering a password into a mobile device, and fingerprint or other biometric method.

The registration module 86 may be configured to enable the user (which may be, among other things, a cardholder, a valid credential holder, or an individual appropriately approved by the issuer) to register for other alternate accounts and other valid credentials. The enablement module 90 may be used to allow the user to enable or disable certain modes or types of transactions based on various uses that the user may engage in based on various criteria, or to allow the user to enable or disable certain transactions on their own prior to authentication. The enablement module 90 may be used to allow the user to choose among a variety of scenarios or criteria for which valid certificate to pay. The reporting module 92 allows the user to report if the payment device 36, 60 is lost or stolen. One embodiment of the reporting module 92 may enable the account association device 24 to manually or automatically report relevant information to the user or issuer 28, including reporting all alternative account details and/or potential fraudulent activity on the payment device. The monitoring module 94 allows the user to view previous transactions to monitor all activities of the device.

The provisioning module 88 may allow the user to distinguish between multiple different sets of alternate account details, respectively.

Traditional device issuance systems may assume that certain data elements are shared between microchips, magnetic strips, and printed/embossed account numbers. However, in contrast to conventional device distribution systems, provisioning module 88 allows for each of these schemas and additional elements and/or schemas to be provided using separate data elements. Provisioning module 88 is configured to identify these multiple distinct sets of alternate account data, respectively, which may be stored in a common provisioning data file communicated during the card or device provisioning step.

If the payment device 36, 60 is lost or stolen, the user may be exposed to unauthorized use of the payment device. However, while in some countries thieves may be able to make purchases using NFC capabilities within a certain spending threshold (eg, $100), thieves typically cannot use the device's EMV capabilities without the user's PIN code, which This may be entered during the provisioning process using provisioning module 88 . Furthermore, the stolen device cannot be used for electronic or telephone transactions due to the different account details of this separate transaction model.

The provisioning module 88 may further include receiving user identification information that is not printed on the payment device 36 , 60 . According to some embodiments, the provisioning module 88 may use the payment device 36, 60 to set the user's usage rules by requiring presentation of the user's mobile device 20 at the time of transaction. Additionally, the mobile application of the mobile device 20 may also be used to immediately block transactions of stolen devices reported by the reporting module 92 as stolen. The user account module 78 may configure its rules to block this magnetic stripe transaction unless the user unlocks using the mobile application on the mobile device 20 each time. The latter method will effectively prevent the use of counterfeit magnetic strip devices. The user account module 78 may also configure its rules to block transactions from any and all different modes, or to block transactions that meet certain criteria unless the user unlocks these transactions each time.

In one embodiment, a mobile application is available on the user's primary mobile device 20 . The user can use the mobile application to register an alternate account or valid credential into the account association device 24, control the provisioning of valid credentials or association with one or more alternate account details provided to the payment device. The mobile application also allows users to enable or disable authorization for transactions presented through any alternate account on the plastic payment device, report a lost or stolen payment device, and report other authentication factors for sensitive or high value or high risk transactions.

The mobile device 20 may also store alternative account details in memory, which may be associated with "card-present" transactions and "no-card" transactions. These alternate account details may be stored in memory and recalled by the user by entering a password and/or another authentication factor into the mobile device 20 . As a means for interacting with e-commerce websites, mobile applications securely store e-commerce alternative account details and display them to the user upon appropriate authentication with passwords, biometrics, and/or other factors. In another embodiment, alternate account details are transmitted by account association device 24 and received by mobile device 20, which can then be recalled by the user by entering a password and/or another authentication factor into mobile device 20.

Figure 6 shows an example of a proxy device 100 configured to represent a plurality of valid credentials 102a, 102b, . . . , 102n. The details of each valid certificate 102a, 102b, . . . , 102n are combined into a single proxy device 100, which can then be used in place of any valid certificate 102a, 102b, . . . , 102n. Valid credentials 102 may be credit cards, debit cards, loyalty cards, loyalty cards, ID cards, health insurance cards, gift cards, and other cards that include account information, identity information, and other types of data. During use, a user claiming a single proxy device 100 may select any set of valid credentials for normal use, as if the actual valid credentials 102 were presented. In some embodiments, proxy device 100 may include one or more microchips, one or more contactless circuits (eg, NFC circuits), magnetic stripes, printed and/or embossed alternate account numbers, and/or CVV codes . The agent device 100 may also include printed information identifying the user, such as the user's name and contact information.

Figure 7 shows one example of a mobile agent device 104 that may be configured to represent any number of valid credentials 102a, 102b, . . . , 102n as described above. Instead of being configured in the form of a credit card, the mobile agent device 104 may instead be constructed as a mobile phone, smartphone, tablet, wearable mobile device, or another suitable processor-based mobile device. In some embodiments, the mobile agent device 104 may include software and/or firmware downloaded into existing mobile phones, smartphones, tablets, wearable mobile devices, and the like. During use, the mobile agent device 104 may be tapped on an NFC-enabled reader or otherwise used in accordance with other methods described in this disclosure.

FIG. 8 is a flow diagram illustrating one embodiment of a method 110 of enabling transactions that exceed a predetermined threshold. For example, the threshold may be established by the user or by the issuer based on preferences or predetermined rules based on the financial stability of the user. In one example, the threshold may be set to $100. Therefore, any pending financial transaction over $100 will execute the method of Figure 8.

In operation, the reading step (1) is performed between a proxy device (eg, proxy card 100 or mobile proxy device 104) and a reader 112 associated with the merchant. Reader 112 may be one embodiment of merchant terminal 16 shown in FIG. 1 . The reading step (1) involves handing over the proxy device 100, 104 to the cashier or the customer using the proxy device 100, 104 himself. The proxy device 100, 104 is swiped across the magnetic stripe sensor of the reader 112, tapped on the NFC sensor of the reader 112, inserted into the chip slot of the reader 112, or otherwise manipulated to cause a read The reader 112 is capable of reading financial information stored in the agent devices 100 , 104 .

In step (2), the bank identification number (BIN) associated with the agent device 100, 104 is sent to the payment processor 114, which may be a third party representative for processing various Credit and debit transactions. For example, payment processor 114 may be a suitable processor for processing a single card or proxy device. In step (3), authorization is performed, which includes the payment processor 114 marking the user payment for authorization by an authorization module 116, such as a padloc ^™ or another authorization module. The transaction details are sent to the authorization module 116 , which may include an application that has been downloaded to the user's mobile device 20 . In some embodiments, mobile device 20 may be the same device as mobile agent device 104 for both initiating transactions (step (1)) and receiving authorizations (step (3)).

Step (4) of method 110 includes communicating with the user to receive a selection of one of a plurality of valid credentials 102 represented by a single proxy device 100 , 104 . The authorization module 116 receives the user's selection and any PIN or other security code required to complete the transaction. In step (5), the authorization module 116 includes securely retrieving the details of the selected certificate from the certificate selection database 118.

In step (6), the authorization module 116 sends the payment information with the BIN code to the issuer of the selected card. The payment processor 114 receives the payment information and BIN code information and sends the information to the appropriate issuer to process the payment (step (7)).

FIG. 9 is a flowchart illustrating another embodiment of a method 120 of enabling transactions below the predetermined threshold described in FIG. 8 . According to the above example where the threshold is set to $100, any pending financial transaction below $100 will execute the method of FIG. 9 . In this embodiment, the user may preselect a valid certificate to use when the transaction falls below the threshold. In this way, smaller transactions can be simplified without some of the extra steps described in Figure 8.

The device shown in FIG. 9 may be the same as the device in FIG. 8 . Moreover, steps (1) and (2) of FIG. 9 are the same as those of FIG. 8 and will not be repeated here. However, step (3) involves sending the identified user payment preferences and retrieving the selected valid certificate from the certificate selection database 118 . Step (4) includes sending payment information with a BIN code to the payment processor 114 for the pre-selected issuer of the valid certificate. Step (5) includes processing the payment as usual.

Figure 10 illustrates one embodiment of a method 130 of operation in accordance with the present invention. A user conducts a transaction at a point-of-sale (POS) device 132 using the proxy card 100 (or mobile proxy device 104). The POS device 132 sends encrypted financial messages that conform to at least one financial transaction standard including, for example, ISO 8583, ISO 20022, and AS 2805. The encrypted message is received by a merchant acquirer 134, which may be configured to decrypt the message and re-encrypt the message for a payment switch 136, which may be configured to process the encrypted and/or tokenized financial transaction information. Encrypted financial transaction messages may be stored in encrypted database 138 .

Payment switch 136 is configured to forward the raw encrypted message from merchant acquirer 134 to the transaction repository of transaction server 142 for tokenization. The transaction repository of transaction server 142 decrypts the original message and sends the tokenized message back to payment switch 136 . The transaction rules engine 140 may be configured to exchange the proxy token for the target credential token. Also, the transaction rules engine 140 may be configured to edit the rules as needed.

The payment switch 136 then provides the selected valid credentials and the requested transaction edited token to the transaction guardian 146 of the transaction server 142 . Transaction Guardian 146 and Transaction Deny Rules are used to validate the rules to allow, deny or other actions on submitted transactions. If the transaction is allowed, the transaction guardian 146 passes the original message to the target token according to the editing rules. The transaction repository of the transaction server 142 returns the encrypted and edited transaction message to the payment switch 136 . Payment switch 136 then encrypts the message and sends the encrypted message to merchant acquirer 134 .

Figure 11 is a flow diagram of one embodiment of a method 160 for securely storing and making a valid credential accessible via a proxy device. The method 160 includes using the proxy device (the proxy card 100 or the mobile proxy device 104 ) to load the valid credential details into the data store 162 of the account association device 24 . Valid certificate details may be obtained using a magnetic brush reading method or any other means to obtain alternative account details from other modes of the payment device. The alternate account details associated with the used schema are sent to the credential management device 164 . The certificate management device 164 is configured to send the encrypted swipe data to the certificate device 180 of the certificate transfer device 174 of the issuer 172 .

Payment switch 166 exchanges inbound data 168 with tokenizer 176 of certificate transfer device 174 and outbound data 170 with decryption device 178 of certificate transfer device 174 . The certificate transfer device 174 also exchanges encrypted certificate data with a data store 186 that stores the data in encrypted form. The certificate transfer device 174 also exchanges the decrypted certificate decrypted by the decryption device 178 with the certificate data store 182 . The key from key cache 184 is provided to certificate transfer device 174 . The keys may include pod specific credential data store keys, derived tokenization keys, and swiper keys. The high-speed memory HSM 188 provides the key cache 184 with the swipe key, the per-pane CMAC, the pane-specific storage key, and the derived tokenization key.

FIG. 12 is a financial information transmission method 196 for a financial transaction. Acquirer 198 sends an ISO8583 message or other message type to upstream channel 200 . The upstream channel 200 sends an ISO 20022 message (canonical) to the switch 202 . The switch 202 sends the PAN and expiration information to the tokenization pane 204 of the account association device 24 . The tokenization pane 204 sends the PAN and token back to the switch 202 . The switch 202 then sends the ISO 20022 (whitelist key) to the mapping pane 206 of the account association device 24 . The mapping pane 206 compares the mapping and sends the mapping action back to the switch 202, which then applies the mapping action. Switch 202 then sends the mapped PAN token to decrypt pane 208 of account association device 24 . The decryption pane 208 then sends the decrypted certificate data back to the switch 202 .

The next few steps may be optional in some embodiments and may involve a log sending function when related to atomic IDs. The switch 202 sends the mapped and sanitized mapped 20022 message to the log pane 210 of the account association device 24 . Log pane 210 sends a confirmation message back to switch 202 . The switch 202 then sends the mapped 20022 message to the downstream channel 212. Downstream channel 212 then sends the mapped 8583 message or other message type to issuer 214.

The issuer 214 sends back the downstream channel 212 a response to the ISO8583 message or other message type. Downstream channel 212 sends a response 20022 message to switch 202, which then applies the inverse transform of the cached map.

The next few steps may also be optional and may involve log sending functionality when related to atomic IDs. As described above, switch 202 sends a mapped and sanitized mapped 20022 message to log pane 210, and log pane 210 responds with an acknowledgment signal. In this embodiment, the switch 202 then sends a 20022 message to the upstream channel 200, and the upstream channel 200 sends an 8583 message or other message type to the acquirer 198.

FIG. 13 is a method 220 of operation of a tokenization process for user registration. User 222 uses card swipe 224, card swipe accessory 226 connected to mobile device 228, and/or mobile device 229 to obtain a valid credential. The encrypted card information is sent to a network service 230 , such as the account linking device 24 . Web services 232 include a registration application programming interface (API) 234 and a tokenizer 236 . Enrollment API 234 allows a user to enroll one or more credentials to associate credentials with proxy devices 100 , 104 . Tokenizer 236 assigns tokens to certificates. The registered certificates and tokens are stored in a database 238, such as the database 30 shown in FIG. Also, the exchange cache 240 may be used to store a mapping of tokens to corresponding certificates.

FIG. 14 shows a method of operation 250 for a tokenization process for registration. User 252 may create an account with a financial institution or issuer 254 . During the registration process, customer data is securely sent 256 from the issuer 254 to the account linking device 258 or other web server. Account association device 258 may correspond to account association device 24 shown in FIG. 1 and includes registration API 260 and tokenizer 262 . Registration and token data are stored in database 264 and exchange cache 266 .

Figure 15 is a schematic diagram of a transaction flow. In a first embodiment of the process, the user presents the payment device 100 at a first merchant 302 of the plurality of merchants. The first merchant 302 initiates a payment transaction using the first account details from the user payment device 100 and sends the financial transaction to the acquirer 306 . Acquirer 306 sends the financial transaction to issuer processor 310 . The acquirer 306 may optionally use the scheme 308 to send the financial transaction to the issuer processor 310 . The issuer processor 310 sends the financial transaction to the account association device 312 which maps the first alternate account details to the first valid credential and sends the financial transaction to the issuer of the first valid credential 316 . The account linking device 312 may optionally send the financial transaction to the scheme 314 which in turn sends the financial transaction to the issuer of the first valid certificate 316 . The response from the issuer 316 follows the reverse path to the merchant 302 . In a second embodiment of the process, the user presents the payment device 104 at a first merchant 302 of the plurality of merchants. The second merchant 304 initiates a payment transaction using the second account details from the user payment device 104 and sends the financial transaction to the non-partner acquirer 320 . The non-partner acquirer 320 sends the financial transaction to the issuer processor 310 using the scheme 308 . The issuer processor 310 sends the financial transaction to the account association device 312 which maps the second account details to the second valid credential and sends the financial transaction to the issuer of the second valid credential 316 . The SecureOne solution 312 may optionally send the financial transaction to the solution 314, which in turn sends the financial transaction to the issuer of the second valid certificate 316. The response from the issuer 316 follows the reverse path to the merchant 304 .

If the transaction is between partner acquirers such as those represented by Merchant A 302, account linking device 312 exchanges credentials as partner acquirer 306. Partner acquirer 306 routes the transaction to issuer 316 and settles the transaction as usual. Account linking device 312 is configured to log all transaction activity.

When a transaction occurs between non-partner acquirers, such as those represented by Merchant B 304 , non-partner acquirer 320 routes the transaction to a partner acquirer, such as acquirer 306 . The account linking device 312 acts as a partner acquirer to exchange certificates and record transaction activity. In this case, a second level interchange fee may apply.

Accordingly, account linking device 312 may be configured to exchange credential data, collect transaction data, and settle transactions. The account association device 312 may also enforce user rules requiring verification of the user's presence in a transaction, and may involve consumers, issuers 316, 322 and/or other parties in the process of identifying fraud.

16-20 are flowcharts showing an overview of the transaction flow process. Figure 16 may be a conventional method 330 for conducting a transaction. In this example, the cardholder 332 or user uses the proxy device 100, 104 to make a purchase with the merchant 334. Merchant 334 obtains transaction information, such as first account information, and creates an authorization request. Merchant 334 passes this information to acquirer 336 . The acquirer 336 then passes the authorization request to the scheme or switch 338 , which then sends the authorization request to the issuer 340 . Issuer 340 responds to the authorization request from merchant 334 with an authorization response sent via the reverse path to the merchant.

In FIG. 17 , the method 330 of FIG. 16 includes account linking means 352 , which may correspond to the account linking means 24 shown in FIG. 1 . Account association means 352 may include proxy translation means 354 . In this embodiment, the issuer 340 is the issuer of both the first account details and the first valid certificate details. The transaction proceeds in the usual manner as described in FIG. 16 , except that the scheme/exchange 338 sends an authorization request to the account association device 352 .

Account association means 352 places the first authorization request on hold. The proxy translator 354 analyzes the consumer rules to map the first account details to alternate valid credentials. Account linking device 352 creates a second authorization request (which may be a new financial transaction or a direct API call to the issuer), and account linking device 352 sends the second authorization request to issuer 340 .

Issuer 340 processes the second authorization request and sends a response. Account association device 352 uses the second authorization response request to create a response to the first authorization request and sends the response to merchant 334 .

The method 360 in Figure 18 is the same as the method 350 of Figure 17, except that in this embodiment issuer (agent) 362 is the issuer of the first account detail and issuer (certificate) 366 is the issuer of the first valid certificate detail G. In method 360 , the transaction flow is the same as in method 350 , except that account association device 352 sends a second authorization request to scheme/switch 364 , which sends the second authorization request to issuer (certificate) 366 .

Issuer (Certificate) 366 processes the second authorization request and sends a response. Account association means 352 uses the second authorization response request to create a response to the first authorization request and sends the response to the merchant.

The method 370 in Figure 19 is the same as the method 350 of Figure 17, except that in this embodiment a third-party token repository 372 is included in the transaction flow. In this embodiment, the cardholder 332 may be the device on which the tokenized surrogate first account details are stored. The merchant creates a first authorization request containing the tokenized alternate first account details and sends the first authorization request to the plan/exchange in the same manner as described for method 350 of FIG. 17 . However, in the method 370, the scheme/exchange 338 sends the tokenized alternate first account details to the third party token store 372, which translates the token into the de-tokenized alternate first account details and The de-tokenized alternate first account details are sent to the scheme/exchange. The scheme/exchange then sends the de-tokenized alternate first account details to the account association means 352. After receiving the response, account association device 352 processes the response in the manner described in method 350 .

The method 380 in FIG. 20 is the same as the method 370 of FIG. 20, except that in this embodiment, the issuer (agent) 362 is the issuer of the first account detail and the issuer (certificate) 366 is the first valid certificate detail issuer. In method 380 , the transaction flow is the same as in method 370 , except that account association device 352 sends a second authorization request to scheme/switch 364 , which sends the second authorization request to issuer (certificate) 366 . Issuer (Certificate) 366 processes the second authorization request and sends a response. The account association device 352 uses the second authorization response request to create a response to the first authorization request and sends the response to the merchant in the manner described in method 370 .

The various implementations described herein represent various possible implementations and examples, and are not intended to limit the present disclosure to any particular implementation. Rather, various modifications may be made to these embodiments, as will be understood by those of ordinary skill in the art. Any such modifications are intended to be included within the spirit and scope of this disclosure.

Claims (13)

1. A system, comprising:

a point-of-sale (POS) device configured to obtain a proxy certificate corresponding to a valid certificate of a user from a mobile proxy device as part of a financial transaction and to send an encrypted financial message including the proxy certificate to a merchant acquirer;

a merchant acquirer configured to receive, decrypt, re-encrypt financial messages to generate an original encrypted message including the proxy certificate, and send the original encrypted message to a payment switch;

a payment switch configured to receive the original encrypted message from the merchant acquirer and send the original encrypted message to an issuer processor;

an issuer processor configured to receive the original encrypted message from the payment switch and send the proxy certificate to an account association device;

account association means configured to receive the original encrypted message from the issuer processor, decrypt the original encrypted message, generate an edited transaction message, and re-encrypt the edited transaction message, the edited transaction message including a tokenized message including a valid credential of the user corresponding to the proxy credential; and

an issuer for receiving the re-encrypted edited transaction message from the account association device, sending a response message indicating whether to accept or decline the financial transaction based at least in part on the re-encrypted edited transaction message;

wherein the account association means is configured to generate an edited response message from the response message by reversing the mapping from the proxy certificate to the user valid certificate and to send the edited response message to the merchant acquirer.

2. The system of claim 1, wherein the mobile proxy device is in the form of a card.

3. The system of claim 1, wherein the mobile proxy device is a smartphone.

4. The system of claim 1, wherein the account association device is configured to select a valid credential for the user from a plurality of credentials based on configurable rules related to usage of the mobile agent device.

5. The system of claim 4, wherein the configurable rules are predetermined by at least one of a user of the mobile proxy device and the issuer.

6. The system of claim 5, wherein the configurable rules are generated by the user using a web browser on a mobile device or computer.

7. The system of claim 5, wherein the configurable rules are generated by an operator associated with the issuer.

8. The system of claim 4, wherein the configurable rule depends on a computed location of the mobile proxy device.

9. The system of claim 4, wherein the configurable rule depends on a value of a transaction.

10. The system of claim 1, wherein the account correlation device is configured to generate the edited raw transaction message using a customizable rules engine.

11. The system of claim 1, further comprising:

a transaction repository configured to:

decrypting and tokenizing the original encrypted message to produce the tokenized message; and

sending the tokenized message.

12. The system of claim 1, further comprising:

a transaction guardian configured to receive the selected valid certificate and the requested transaction-edited token.

13. The system of claim 12, wherein the transaction guardian is further configured for verifying the original encrypted message and the original transaction of the requested transaction compilation.

Images