DESC:TECHNICAL FIELD
The present invention is in relation to methods of management of financial account. More particularly to systems and method of management of financial transactions involving cards; smart card or magnetic stripe card of clients, with the aid of a handheld device to specifically restrict the usage of the card and/or daily transaction limits; at Automated Teller Machine and/or Electronic Data Capture Machine at the point of sale.

BACKGROUND
The improvements in handheld communication devices, specifically in the area of mobile phones are helping to beget many technological advantages. The advantages are associated to the development of mobile applications for a specific use.

A mobile application is usually defined as a software application developed specifically for use on small, wireless computing devices, such as smart phones and tablets, rather than desktop or laptop computers.

The mobile applications are created to meet various requirements in different sectors. The applications are user friendly involving simple steps to get the required software and link it to the use on the mobile phone.

Owing to the tedious task involved in the banking sector coupled with the requirements on safe transactions, banking sector has become a much sought after platform for the development of mobile applications as it can be personalized with the account holder with his mobile number.

With the increasing scope of Net Banking, ATM transactions, Debit and Credit card transactions, the Bank account holder often faces the following difficulties. The customer has to be extra careful about their Debit and Credit cards from any theft, misplace or misuse. The protection in a said instance is to approach the bank and block it by hot listing the card through debit card management system linked with the EFT switch. This often faced the problem of delay in response from the time the customer reported loss of card to the bank to the time the card was hotlisted. Once the card is blocked, the card status changes to hotlisted state and it cannot be used for any transaction. Subsequently unlocking the card, customer has to:
a) Approach the branch to de-hotlist his card and
b) Apply for a new debit card

Further, there is no facility to restrict the card usage on a temporary basis depending upon the customer needs. Also, there is no facility for changing the card limit. If a customer wants to restrict his card limit for use in ATM alone or Point of Sales alone, he had no provision to do so.

The present invention provides a mechanism to solve the above mentioned problems and protect the debit card holder’s account from any misuse by restricting the transaction amount to a specific amount. The mechanism can be controlled by the mobile application of the present invention by the account holder with the help of his mobile phone.

STATEMENT OF INVENTION
Accordingly the present invention provides a system implemented method for restricting financial transaction involving a card relating to a financial account, through account holder’s device, comprising: a) receiving, by one or more processors, information relating to the account holder, wherein the information includes name, account number and nature of transaction through the card, b) generating, by one or more processors, request to restrict the financial transaction of the account, c) receiving and identifying, by one or more processors, the input on nature of the financial transaction, d) customizing the account, by one or more processors, for financial transaction, as per the input, and e) toggle the account, by one or more processors, through a request for financial transaction from account holder’s device; and a financial account management system, for restricting financial transaction involving a card relating to a financial account, through account holder’s device; comprising one or more memory component storing software instructions; and one or more processors configured to execute the instructions to: receive by the one or more processors, details of account holder, whose financial account is to be restricted for financial transaction involving card and implement the input instructions on the account holders device through one or more processors.

BRIEF DESCRIPTION OF FIGURE
Figure 1: Architecture of IB Smart Remote application.

DESCRIPTION OF INVENTION
The foregoing description of the embodiments of the invention has been presented for the purpose of illustration. It is not intended to be exhaustive or to limit the invention to the precise form disclosed as many modifications and variations are possible in light of this disclosure for a person skilled in the art in view of the figures, description and claims. It may further be noted that as used herein and in the appended claims, the singular forms "a", "an", and "the" include plural reference unless the context clearly dictates otherwise. Unless defined otherwise, all technical and scientific terms used herein have the same meanings as commonly understood by person skilled in the art.
The present invention is in relation to a system implemented method for restricting financial transaction involving a card relating to a financial account, through account holder’s device, comprising:
a) receiving, by one or more processors, information relating to the account holder, wherein the information includes name, account number and nature of transaction through the card;
b) generating, by one or more processors, request to restrict the financial transaction of the account;
c) receiving and identifying, by one or more processors, the input on nature of the financial transaction;
d) customizing the account, by one or more processors, for financial transaction, as per the input; and
e) toggle the account, by one or more processors, through a request for financial transaction from account holder’s device.
In an embodiment of the present invention, the financial transaction involves Automated Teller Machine or Electronic Data Capture Machine at the point of sale.
In still another embodiment of the present invention, the card is selected from a list comprising debit card and credit card.
In still another embodiment of the present invention, the account holder’s device is a mobile phone, tablet phone or computer.
In still another embodiment of the present invention, five accounts can be managed by the method.
The present invention is also in relation to a financial account management system, for restricting financial transaction involving a card relating to a financial account, through account holder’s device; comprising one or more memory component storing software instructions; and one or more processors configured to execute the instructions to:
receive by the one or more processors, details of account holder, whose financial account is to be restricted for financial transaction involving card; and
implement the input instructions on the account holders device through one or more processors.
In still another embodiment of the present invention, the input instructions relates to transaction through Automated Teller Machine or Electronic Data Capture Machine at the point of sale.
The present invention is in relation to system and method, more specifically “mobile application” for use in the banking sector to protect the account holder from any misappropriation of his/ her card. The method is a simple and efficient way to help the Bank’s card holders to control the card status and daily transaction limits of their card (bank accounts) remotely through user-friendly menus on their hand held devices. It helps the card holders to protect their cards by locking the card usage when not in use and also by reducing the daily usage limit up to a minimum of Rs.100 for ATM withdrawal and Rs.1 for Point of Sales (POS) transaction.

The invention termed as ‘IB Smart Remote’ an application for handheld devices can be downloaded and installed by the account holders on their smart phones; Android based, IOS based or Windows based hand held device and used to restrict the usage of the card as mentioned above. The customer’s mobile number is linked to the cards after validating the customer through OTP and PIN verification.
The system toggles the card status between “restricted mode” and “open mode”. Financial transactions cannot be performed using the card when the card is in restricted mode, which provides protection from fraud / misuse of misplaced or lost debit cards. The system provides integration to change the status of card directly in EFT switch. Also, it is easy for the customer as the control is with customer.

Though the system, can be used to restrict the financial transactions in the “Restricted” mode, it can still be used for non-financial transactions like balance enquiry. The card can be reverted to “Open” status and used for all transactions later as per the requirement of the customer.

The system provides facility for restricting the transactions of Automated Teller Machines (ATM) or Electronic Data Capture (EDC) machine or both.

The following services are offered through the application:
i. Toggle the card status between “Restricted mode” and “Open mode”. Financial transactions cannot be performed using the card when the card is in restricted mode.
ii. Increase / decrease the withdrawal limit for ATM & EDC at the Point of Sales (POS) channels within the maximum limit permitted by Bank for each card type.
iii. Set limits for individual Debit cards linked to the account.

Technical process flow of the system involves the following steps, the flow is schematically depicted in Figure 1:
1. Account Registration
2. Profile View
3. Balance enquiry
4. Card Registration
5. Card Enquiry
6. Toggle Debit Card Status between Open / Restricted
7. Card Limit Change – Per day ATM Limit / POS Limit
8. Toggle Credit Card Status between Open / Restricted

Account Registration:
After successful downloading of application as a first time user, the user is prompted to carry out account registration. User can add upto 5 accounts in the application. The user specific information i.e. account number, registered mobile number and password along with API handshake token key will be validated by the Mobile Application Server through the web server on HTTPS secured 128-bit encryption. Mobile Application server will verify the API handshake token to confirm whether the request is received from the correct mobile application hosted by the Bank. After verification, the mobile application server logs the request in the Log File and checks the Database for the existence of requested account number. If account number already exists (registered) then the application rejects the request with the remarks “Account already registered”. The chart 1 depicts the steps involved in the process.

Chart 1.

In the step 2, the system constructs the request message in XML format consisting of users 9 digit / 10 digit account number and sends the same to Core Banking Server (CBS) through an intermediate server in the form of a post method. CBS verifies the account number and if account number is wrong, CBS declines the transaction and sends the negative response. Response gets stored in database, and the error message “Invalid User Details” get displayed to user. If the account number is correct and valid, then CBS responds back with user information like Account holder’s name, User ID (CIF number), Account Type, Account status, PAN number, Date of Birth, Product code, Registered Mobile Number and other details. The step 2 is depicted in the Chart 2.
Chart 2

After getting response, in the step 3 the mobile application server will match the Registered Mobile Number entered by the user and the registered mobile number received from CBS. If both are not matching, application declines the transaction and logs appropriately in log file. If both the mobile numbers are matching, then password entered by the user along with registered mobile number, Mobile Model, Mobile OS version, Device ID are stored against the account number and CIF number in the database. These details are used to validate and restrict registration of same account number on different devices as depicted in the chart 3.

CHART 3

In step 4, the application generates an OTP for validation & completion of the registration process and the validity of the OTP is 15 minutes. The OTP is a 6 digit random number generated by the application and the same is stored in the database in an encrypted format against the device ID. The OTP is sent to the SMS gateway server and the SMS gateway server forwards the same to the Bank’s SMS vendor. Till the time OTP is entered by the user, user’s account registration status will be in Unregistered Status (UR). Once the time is lapsed, then the record pertaining to that OTP gets deleted from the system. Also, once the OTP is entered/ validated within the time period, then also the record pertaining to that OTP gets deleted from the system. If OTP is entered within the time validity and successfully validated, the account status gets changed to Active (AC) state in database and registration process will get complete. After successful registration the mobile application displays the menu for account addition, Credit Cards and view profile. The sequence of events is shown in chart 4.
CHART 4

Profile View:
The Profile menu contains the user specific information. Every time the user selects this menu, a request is sent from the mobile application server to CBS as post request for fetching the current profile information as depicted in chart 5.

CHART-5

Balance Enquiry
Account balance information is available in the data returned by CBS server as response post the request.
Card Registration
In step (a), after successful account registration, user can register their cards linked with the registered Account number by selecting “Add Card” menu. User has to enter his 16 or 19 digit Card number, PIN number of the card and expiry date. Once PIN number is entered, application converts the PIN into PIN BLOCK based on the encryption algorithm available in the mobile application. On clicking on submit, application performs the preliminary checks on the received information (like Card length) and the encrypted data will be passed to IFS over secured https tunnel. IFS redirects the request to mobile application server. After verification, the application checks for the availability of the card number in the database. If card already exists, application declines the transaction with error message “Card already exists” explained in as schematically in chart 6.

CHART-6
Step a:

If there is no existing card entry in the database, in the step 2 application constructs an XML-SOAP message and encrypts the PIN BLOCK using the triple DES keys shared between WebGate server (EFT Switch) and Mobile application server. WebGate station sends the request to the EFT Switch HISO process to verify the received data and create an ISO request and forwards the same to the WebGate Auth process. The Auth process decrypts the PIN BLOCK and sends the same for Card verification to Host Security Module (HSM) for the verification of the PIN entered by the user. It checks for the card status, linked account number and expiry date of the card maintained in Card Authentication File (CAF) in switch and returns the following response codes as given in Table 1.
Table 1: List of response codes
00 - Approved 14 - Invalid card 55 - Incorrect pin
89 - Data base problem

05 - HSM parameter error/
HSM failure 30 - Format error 75 - PIN tries exceeded 91 - Destination not available
12 - Invalid transaction 54 - Expired card 88 - System error 92 - Invalid destination

If any of the entered data is invalid, then the Auth process declines the transaction with appropriate response code. If entered data is valid, then the EFT Switch generates the response with response code ‘00’ with the linked account number and sends it back to the mobile application server.
The Mobile application server matches the received account number with the registered account number from which request is generated. If both are not matching, then the application declines the transaction with appropriate response message. If both account number matches, it registers the card against the account number in encrypted format in the database and set the status of the card to ACTIVE (AC) as depicted in chart 7.
Once card is registered, the card number is displayed in masked format when the user logs in to the application (step (b)).

CHART 7

Step (b):

Card Enquiry
On selecting the registered card number, the mobile application generates card enquiry request and sends to the IFS server, which in turn redirects the request to the mobile application server. Mobile application server sends this request to the EFT Switch as FHM request (0300) in ISO 8583 format. FHM station for mobile application receives the request and forwards the same to the FHM HISO process for doing the preliminary check and retrieving the required information in ISO format (0310). HISO process sends a response back with card status, card type, expiry date, aggregate card limit, individual ATM and POS limits etc. The Mobile application reads the response and generates an XML response back to the IFS which forwards the request to requesting device. The values passed by EFT Switch are getting displayed to the user in the mobile application. The information is schematically depicted in chart 8 below.
CHART 8

Toggling Debit Card Status between Open and Restricted modes:
User now may use this application for toggling the card status between Open and Restricted modes and for updating the per day card limit for ATM and POS transactions. As per the FHM enquiry response as in part 4 detailed above, Mobile application displays the card status either Locked or Unlocked. If card status is Locked, user may toggle the same to Open. Once card status is open, Mobile application allows user to change the per-day-limits for ATM and POS. While clicking on submit, mobile application sends an XML request over HTTPS secured channel to the IFS. IFS sends the XML request to the application server which constructs a 0300 FHM request message for updating in CAF file and sends the request to the FHM station. FHM station sends this request to FHM HISO process, HISO process checks for the fields available in the requested ISO message. If all fields are correct, it updates the status on the CAF file for the requested record. It updates the user ID of the requester application (100,105) to distinguish the user initiating the update request. HISO process sends the response (0310 FHM ISO message) with response code ‘00’ to the mobile application server. Mobile Application server creates an XML response, logs the response and sends it to the requesting device over secured channel (Chart 9).
CHART 9

Card Limit Change – Per day ATM Limit / POS Limit:
If card status is open, then it will allow user to update the limit as per the product limit set by the Bank. For each product, maximum limit is stored in the database and during each enquiry request; the application fetches the maximum online limit for the card product individually for ATM and POS transaction. User may set individual limits within the range permitted for each card product. Card Limit can be changed for a card only if it is in Open State. If the current card status is in “Restricted” state, then the application will not allow user to alter the limits. In order to change the card limit, user has to change the card status to Open and then send the request for changing the limits.
While clicking on submit, mobile application sends an XML request over HTTPS secured channel to the IFS. IFS server sends the XML request to mobile application server. Mobile Application constructs a 0300 FHM request message for update in CAF file and sends the same to FHM station. FHM station sends this request to FHM HISO process, HISO process checks for the fields available in the requested ISO message. If all fields are correct it updates the limit on page 1, 8 and 9 of the CAF file for the requested record. It updates the user ID of the requester application (100,105) to distinguish the user initiated the request. HISO sends the response (0310 FHM ISO message) with response code ‘00’ to the mobile application server. Mobile Application server creates an XML response, logs the response in the database and sends it to the requesting device over secured channel (chart 10).

CHART 10

Toggling Credit Card Status between Open and Restricted modes:
Every time the user selects Credit Card option, a request is send from the mobile application server to server of Credit Card service provider as post request for locking card and unlocking card:
Credit card server locks/ unlocks credit card linked with the mobile number sent along with the request, responds to the Mobile application server with appropriate response, which in turn communicates the same to the user as indicated in chart 11.

CHART 11

Thus, the present invention provides a method and system to protect the cards of customers of banks from misappropriation.
The aforesaid description is enabled to capture the nature of the invention. It is to be noted however that the aforesaid description and the appended figure illustrate only a typical embodiment of the invention and therefore not to be considered limiting of its scope for the invention may admit other equally effective embodiments.
It is an object of the appended claims to cover all such variations and modifications as can come within the true spirit and scope of the invention.
,CLAIMS:We Claim:
1. A system implemented method for restricting financial transaction involving a card relating to a financial account, through account holder’s device, comprising:
a) receiving, by one or more processors, information relating to the account holder, wherein the information includes name, account number and nature of transaction through the card;
b) generating, by one or more processors, request to restrict the financial transaction of the account;
c) receiving and identifying, by one or more processors, the input on nature of the financial transaction;
d) customizing the account, by one or more processors, for financial transaction, as per the input; and
e) toggle the account, by one or more processors, through a request for financial transaction from account holder’s device.
2. The system implemented method as claimed in claim 1, wherein the financial transaction involves Automated Teller Machine or Electronic Data Capture Machine at the point of sale.
3. The system implemented method as claimed in claim 1, wherein the card is selected from a list comprising debit card and credit card.
4. The system implemented method as claimed in claim 1, wherein the account holder’s device is a mobile phone, tablet phone or computer.
5. The system implemented method as claimed in claim 1, wherein five accounts can be managed by the method.
6. A financial account management system, for restricting financial transaction involving a card relating to a financial account, through account holder’s device; comprising one or more memory component storing software instructions; and one or more processors configured to execute the instructions to:
receive by the one or more processors, details of account holder, whose financial account is to be restricted for financial transaction involving card; and
implement the input instructions on the account holders device through one or more processors.
7. The financial account management system as claimed in claim 6, wherein the input instructions relates to transaction through Automated Teller Machine or Electronic Data Capture Machine at the point of sale.