Patent Application
20170178131
The present invention relates to a transaction system and method. The transaction system and method are particularly relevant, but not limited to facilitating secure mobile wallet transactions and will be described in such context.
Each document, reference, patent application or patent cited in this text is expressly incorporated herein in their entirety by reference, which means that it should be read and considered by the reader as part of this text. That the document, reference, patent application, or patent cited in this text is not repeated in this text is merely for reasons of conciseness.
The following discussion of the background to the invention is intended to facilitate an understanding of the present invention only. It should be appreciated that the discussion is not an acknowledgement or admission that any of the material referred to was published, known or part of the common general knowledge of the person skilled in the art in any jurisdiction as at the priority date of the invention.
Rapid advancement in the development of mobile devices and related software applications (hereinafter referred to as ‘apps’) has resulted in increasing e-commerce transactions performed because such advancement in technology offers users the convenience of con the go′ transactions as long as any type of connection (GSM, GPRS, 3G, Wi-Fi etc.) can be established to the Internet. In particular, credit card users or fund source owners now enjoy unprecedented electronic transaction, such as electronic shopping experience as they may now choose from a variety of transaction channels/modes instead of the traditional point of sale (POS) or related electronic transfers requiring the use of dedicated end terminals which typically are located only at designated locations where the sale takes place.
The availability of increasing transaction channels/modes inadvertently lead to the increasing occurrences of fraud/security breach, where information of credit card users such as PAN, CVC2, Expiry Date, etc. are exposed due to insecure websites or hacking activity. Despite the efforts of card issuers and acquirer in the financial industry encouraging the implementation of a variety of financial security standards (SSL, EMV Chips and 3D secure) etc., such security standards would secure the transaction channel and/or the transaction device to certain extent but are not an effective fool proof way of preventing scheming, theft and internal fraud. Moreover, not all electronic merchants are mandated to implement those security compliance/standards, and unaware credit card users may inadvertently subject/avail themselves to such ‘insecure’ transaction channels.
As an example, a credit card holder wishes to reserve an airline ticket and thus access an online reservation/booking website. To make payment via credit card for completing the online reservation, standard well-known process is to provide the cardholder information like Card Name, PAN (Primary Account Number or card number), CVC2 and Expiry Date. If these transaction data are not properly protected and obtained or intercepted by an unauthorized entity while the credit card holder is completing the transaction, the unauthorized entity may use the data for other unauthorized payment transaction or may even fabricate a card and use the fabricated card for transaction just like a legitimate card transaction.
To overcome the potential breach in security, prior art transaction systems that provides additional security by allowing a holder of a financial account card, such as a credit card or debit card, to disable and re-enable use of the card by locking and unlocking the card repeatedly has been disclosed. However, such a system adopts an “all or nothing” approach to the security problem in that no transactions at all can be made when the associated card is in the locked state, and the holder has to unlock the card prior to making any transactions.
The system as described in PCT publication WO2010/147559 describes a system and method that allows a user or provider of a ‘smart card’, such as a credit card, to change the state of a transaction channel, in particular allowing a user or provider to ‘lock’ and/or ‘unlock’ certain transaction channels/modes such as web purchasing, point of sale purchasing, etc. with respect to other transaction modes. The system allows a user or provider the flexibility to ‘choose’ the types of transaction channels that may be used to effect transactions. So, for example, a user may decide that, for security reasons, he/she will ‘lock’ his card to prevent the card from being used for web-based purchases, but will leave the card unlocked for traditional point of sale (POS) purchases. If the user's card is stolen, an unauthorized user would not be able to use the card to effect any web-based purchases, thereby providing an extra level of security while according certain level of flexibility.
The system was further improved as described in PCT publication WO 2013/103323 where card issuers are given the option of the locking/unlocking feature.
While the above systems provide a level of flexibility to a user to disable certain transaction channels instead of the whole account, there exist limitations faced by the user in particular when he wishes to make authorized batch payment to online merchants. In particular, batch mode process involves having the merchants transacting with the user(s) where pre-approval of cardholder transaction is made and actual authorization is suspended for a predetermined period. The merchant system then subsequently executes batch authorization payment to reduce its cost of interchange fee charges on clearing and settlement. Such a scenario is however not transparent to a user (cardholder) such that when the cardholder/user unlocks his account to allow transaction via a transaction channel such as internet purchase by thinking that the pre-approved process was really an authorization from their issuing bank. By the time the batch authorization takes place, the cardholder account status is already back to “lock state” (or back to default) which resulted in rejection of transactions at the stage of pre-authorization validation.
The present invention seeks to improve the transaction systems and methods that reduce or prevent the occurrence of transaction fraud to at least some extent while allowing greater flexibility for the user to perform transaction and greater customization of a selective lock/unlock feature.
Throughout the specification, unless the context requires otherwise, the word “comprise” or variations such as “comprises” or “comprising”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.
Furthermore, throughout the specification, unless the context requires otherwise, the word “include” or variations such as “includes” or “including”, will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.
In accordance with an aspect of the present invention, there is provided a transaction system comprising:
a transaction facilitator operable to receive and process a transaction request from a user device; a transaction channel controller operable to change the state of the transaction channel between a first and a second state; and a fund provider operable to receive processed transaction request and determine if the transaction channel is in the first or second state; and provide or not provide the funds accordingly.
Preferably, the first state corresponds to a state where the transaction channel is locked and forbidden for any transaction.
Preferably, the default state is the first state.
Preferably, the instruction to change the transaction channel from the first to second state and vice versa is initiated by the user device.
Preferably, the fund provider comprises a user profile database operable to automate the instruction to change the transaction channel from the first to second state and vice versa.
Preferably, the user profile database is operable to capture one or more of the following transaction parameters from the transaction request in order to determine whether the transaction channel should be in the first or second state:—Transaction Datetime stamp; Merchant Category Code; Merchant Name; Merchant Address; Transaction Amount; Country Code; or Currency Code.
Preferably, the user profile database is operable to determine the location of the user device sending the transaction request in order to determine whether the transaction channel should be in the first or second state.
Preferably, the transaction channel is one of the following:—point of sale (POS) terminal; Internet transaction; ATM.
In accordance with a second aspect of the present invention, there is provided a transaction method comprising:
receiving and processing from a transaction facilitator a transaction request from a user device;
receiving from a transaction channel controller a request to change the state of the transaction channel between a first and a second state;
wherein the processed transaction request is successful or not successful depending on whether the transaction channel is in the first or second state.
The present invention will now be described, by way of example only, with reference to the accompanying drawings, in which:
Other arrangements of the invention are possible and, consequently, the accompanying drawings are not to be understood as superseding the generality of the description of the invention.
In accordance with an embodiment of the invention there is a transaction system 10 comprising a user device 12 operable to send a transaction request 14 via a transaction channel 16. The transaction channel 16 may be chosen from a plurality of transaction channels 16 available to the user at a specific time period. Each transaction channel 16 may be utilized to access one or more transaction accounts belonging to the user.
The system comprises a transaction facilitator 18 operable to receive and process the transaction request 14 from the user device 12. Transaction facilitator 18 may include a web portal, Internet server, a combination of servers (whether distributed or otherwise), to facilitate the processing of the transaction requests in at least one communication protocol. Examples of communication protocol include SMS, mobile app API etc.
In addition, the system 10 comprises a transaction channel controller 20 operable to change the transactional state of the transaction channel 16 and/or transaction device 12 between a first and a second state. It is to be appreciated that for the change of transactional state of the transaction device 12, the change of state from the first state (lock) to the second state (unlock) would have to take place prior to the actual transaction authorization. Upon receipt of a request for change of state of the transaction device 12, the transaction channel controller 20 is operable to pre-authorize the state for the transaction device 12 prior to any transaction. Otherwise, if the transaction device 12 is not unlocked before any transaction, any transaction(s) will be declined. The changing of the lock/unlock status is not prescribed to be synchronous to the actual transaction request to avoid time-out scenarios.
The system 10 also includes a fund provider or fund source 22 operable to receive processed transaction request and determine if the transaction channel is in the first or second state; and notify the user device 12 accordingly.
Referring to
The transaction device 12 may be is a personal computer, smart phone or any device capable of displaying and interacting with a transaction portal 18 that may include a payment portal. The user interface for displaying and interacting with the payment portal is typically in the form of a website of a payment gateway of a merchant. The website is accessible by a user via a web browser of a personal computer 12 operably connected to be in data communication with other components of the transaction system 10 via a communication network comprising a plurality of transaction channels 16. The user interface for displaying and interacting with the transaction portal 18 may also be in the form of a dedicated software application colloquially known as an ‘app’. The plurality of transaction channels 16 include (but is not limited to) 3G/4G, Wi-Fi connection to the Internet; direct LAN connection to the Internet; point of sale (POS) terminal; or Automated Teller Machines (ATM). It is to be appreciated that amongst the plurality of transaction channels 16, at least one transaction channel 16 may be less secured relative to another transaction channel 16. It is further to be appreciated that each transaction channel can be locked/unlocked individually without the transaction account being locked/unlocked.
The merchant offers good and services for sale, which may be purchased electronically (‘on-line’) by a customer accessing the website.
The use and operation of the Internet, computers and servers using software applications and payment portals are well known to persons skilled in the art and need not be described in any further detail herein except as is relevant to the present invention.
In the embodiment described and with reference to both
In an example, the transaction channel 16 enabled by the user is ‘Internet’. Once Internet transaction channel is enabled, the user 12 may then access the airline reservation website/portal for performing his necessary reservation. Once the reservation is made, the user would be prompted to make payment by choosing his transaction payment preference. If he chooses online electronic payment mode, he will be prompted to key in his preferred credit card number and details such as Card Name, PAN (Primary Account Number or card number), CVC2 and Expiry Date.
Upon keying in the transaction details, the airline reservation website will access the fund source system 22, such as a credit card or bank account, for example, MasterCard™ Worldwide, where the user has an account with.
As the transaction channel ‘Internet transaction’ has earlier been enabled, payment would successfully be debited from the fund source 22 once the credit card number and details are verified to be correct. The successful payment notification will be sent to transaction channel controller 20. The transaction channel controller 20 will then send an electronic transaction receipt in the form of an electronic data such as SMS or an email to notify the user of the transaction device 12 of the successful transaction. Upon successful payment notification, the transaction is then deemed completed.
If ‘Internet transaction’ was not previously enabled, then the fund source 22 rejects the payment request even though the provided credit card details may be valid. An ‘unsuccessful’ notification will then be sent to the transaction channel controller 20. The transaction channel controller 20 will send a SMS or email to the transaction device 12 notifying the user of the unsuccessful transaction.
In another embodiment, the fund source 22 is coupled with one or more user profile databases. The user profile databases may include location based services and are used to capture usage patterns, locations, favourite merchants, transaction amount, countries where most transaction take place, currency of transactions etc. The captured user profile data may be used to automate the change of transaction states between clock′ and ‘unlock’ without the need for a user's manual input provided the user chooses to effect such a feature known as ‘enhanced lock-unlock’. It is to be appreciated that the enhanced lock-unlock feature may be used in conjunction with the manual lock/unlock or as an alternative. In the latter, where there is a conflict between manual and automatic instructions to lock/unlock the fund source, the manual instruction prevails and the automatic lock/unlock instruction is overrided.
Referring to
Prior to activating the enhanced lock unlock feature, a user will be prompted by the fund source system 22 to input the number of transaction parameters he wishes to use for customizing the clock-unlock′ feature. The lower the risk appetite of the user, the more transaction parameters used for customization. For verification, the user may be prompted to enter a password, such as a mobile personal identification number (mPIN) for submission to the fund source 22. The mPIN may also be requested before the user logs in to the transaction portal 18.
Using an example, a user may be presented a list of transaction parameters as a basis for an automatic lock if there is a match for one or more of the value/parameters associated with a transaction request. The parameters include information and data relating to the date, time and location of transaction, merchant information, transaction amount/value, geographical location of user, currency used for transaction, etc. The transaction parameters will be compared with a set of rule-base and logic for determination of whether a transaction channel should be locked or unlocked. Examples of rules and logic include:—
In addition to the defined transaction parameters, location based services (LBS) may be used to enable the risk alert management for the auto-lock feature. An example of using LBS to enable risk alert management is when a user does an ATM Withdrawal in location A (e.g. Singapore) and within a short duration (e.g. a few seconds later) another ATM withdrawal from the same account takes place in location B (e.g. New York). That is a physical limitation of the same person being in two places at the same time and a rule base feature of Risk Alert Management incorporated in the system which is operable to trigger an Auto-lock of the affected account and a notification to the account holder of the declined transaction.
The above LBS based risk alert management rule activation is applicable for face-to-face type transactions where physical presence is required, for example for ATM and POS transactions. In addition, the notification feature to account holder as mentioned above is a unique capability of the system that is much appreciated by the end users, because in some usual cases, declined transactions are not accompanied with such notifications. Such declined transactions may cause problems to the end user who may not know why the transaction has been declined or if a fraud has been detected.
Compared to the current auto-lock facility which is based on the global system settings of minute interval and triggered unlock timestamp, the customization of the clock-unlock′ feature provides a ‘fine-tune’ adjustments depending on users' preference and are not limited by a predetermined period of time as disclosed in PCT publication WO2010/147559.
The described embodiment affords the flexibility for authorization of batch payment to third party merchants, such as online merchants for example if the merchant name and address are not in the blacklist.
To address limitations associated with batch mode processing by merchants, this system, known as the enhanced lock-unlock system, introduces granular options based on the described rules and logic to cardholder to specify and enable certain transaction channels 16 like web-online, POS, ATM, etc. with additional feature to enable per transaction channel 16 white-listed option such as the combination of merchant name, merchant category code, merchant location, etc. This way, the cardholder will only allow any unexpected batch authorization payment executed by the whitelisted merchants (if enabled) and those merchants that are not fall under the backlisted merchants (always enabled but depended on the specified list).
The use and operation of transactions facilitated by credit card companies, such as MasterCard™ Worldwide is well known to persons skilled in the art and need not be described in any further detail herein except as is relevant to the present invention. Mechanisms and elements required to implement the ‘lock’ and ‘unlock’ such as specific processors, Unicard Gateway, Acquirer/Issuer system are found in PCT publication WO2010/147559 and the details of which are incorporated herein by reference.
In another embodiment, the system may incorporate the further feature where card issuers are given the option of locking/unlocking as described in PCT publication WO 2013/103323. The feature as disclosed may be used in combination or in conjunction with the enhanced lock/unlock feature.
In accordance with another embodiment of the invention and with reference to
As shown in
The sign up and registration capability allows a user to personalize the proxy wallet card generated and define a security PIN authentication. It also allows a user to register basic information as compliance for KYC (know-your-customer) and compliance with regulatory requirement such as the Anti-Money Laundering Act (AMLA) that requires certain level of declaration and transparency.
In another embodiment, if the card user has multiple fund sources, he may link his various fund sources as illustrated in
Upon receiving the linking request from the user 12, the proxy wallet and lock/unlock controller 20 validates the same and sends an authorization request to the issuing bank network (if available) via a bank module 21 to verify the legitimacy of the fund source information. Alternatively or in conjunction, the authorization request can also be sent to an acquiring network to verify the legitimacy of fund source information. Upon receipt of the authorization request, the bank module 21 or acquiring/issue network will then send the relevant information for verifying/validating the authorization request and determine the credit line or available balance.
In addition to the multiple linking of fund sources, the user 12 may link all his identifications used for different fund sources via a Multiple Linking of Identification feature. This multiple linking feature links the different or associated identification of cardholder (as the proxy wallet owner) for instant pre-authentication and the acquiring of payment authorization process. This different identification used may include Mobile Number, Email Account, Social-media Account, Government-ID, Plate-number, Transponder ID, Biometric-Scan Data, NFC device ID/sticker, including those identifications that can be utilized for association with specific Merchant or Biller Account.
For instance, if the proxy wallet 200 owner is a regular customer of a particular online shopping facility such as AMAZON™ e-shopping, then he/she can register his log-in account such that upon check-out and he chooses the system acquiring service for payment, the system will automatically detect the corresponding Proxy Wallet 200 Card since the log-in credential from AMAZON™ was already registered as one of wallet owner's ID.
Either or both of the following security features may be utilized for accessing and transacting with the proxy wallet 200.
In addition to the verification function as described, the Cardholder Management Module is also a capability feature which provide self-care User-Interface for a user to allow the following
The Bank Module may include a capability feature to provide standard API (pre-activation & activation, check lock-unlock status, transaction notification via SMS, Apps, email, etc) gateway for easy integration with participating issuing banks partner who are more comfortable for direct integration instead of usual acquiring channel. The bank module can be deployed as part of Proxy Wallet Lock-unlock Control or co-located with bankcard management system (just like MIP of Mastercard™) to provide close-loop and reliable network integration.
The various embodiments described above involve certain level of integration process such as the re-routing of transaction channels to the lock-unlock controller module, rule modification of the card management system; and the activation/linking with the user device 12 via transaction channels such as SMS, STK, Mobile-Apps, and Web-Portal. The embodiments above may be further improved by having a combination of hardware and software to:—
In addition, the above embodiments may be further improved by having a simpler and “seamless” integration options with issuer banks or fund source system.
The proxy wallet 200 service is advantageous in that it provides a physical Card as proxy wallet based on generation of Pseudo PAN for linkage of different fund sources. The proxy wallet 200 also provides a single PIN for pre-authorization security process. This will address the difficulties of managing and maintaining different fund sources account and difficulties to remember different PIN security of each fund sources.
The proxy wallet 200 may be utilized for the multiple Linking of card holders (Proxy wallet owner's) identify (ID) to address the difficulties of managing and maintaining different identification information that is required during the pre-authentication process such as Mobile Number, Email Account, Social-media Account, Government-ID, Plate-number, Transponder ID, Biometric-Scan Data, NFC device ID/sticker, including those ID's that can associate to specific Merchant or Biller Account for online payment or purchase transaction.
The invention offers alternative integration using bank module for direction integration with issuing bank partners.
The invention also addresses the limitation of Paypal proxy virtual account that is not applicable for POS, NFC and RCF face-to-face (F2F) transaction and limited for safe online shopping only.
It is to be understood that the above embodiments have been provided only by way of exemplification of this invention, and that further modifications and improvements thereto would be apparent to persons skilled in the relevant art and as such are deemed to fall within the broad scope and ambit of the present invention described, in particular:—
It should be further appreciated by the person skilled in the art that variations and combinations of features described above, not being alternatives or substitutes, may be combined to form yet further embodiments falling within the intended scope of the invention.
| Number | Date | Country | Kind |
|---|---|---|---|
| 2014008106 | Feb 2014 | SG | national |
| 10201400156Q | Feb 2014 | SG | national |
| Filing Document | Filing Date | Country | Kind |
|---|---|---|---|
| PCT/SG2015/050012 | 2/4/2015 | WO | 00 |
