COMPUTING ENVIRONMENT

FIELD OF INVENTION

[0001] Embodiments of the present disclosure relates to a computing systems and more particularly to a system and method for securing financial transaction in a computing environment.

BACKGROUND

[0002] In banking industry, there are different modes of fund transfers, such as online fund transfers, international remittances, and offline fund transfers, such as cheques, demand draft, and the like. In such modes of the fund transfers, there are risks involved while adding a payee account through online methods or offline methods. For example, in India, length of an account number varies from nine to eighteen-digit code and Indian Financial System Code (IFSC) is an eleven-digit code. Therefore, while typing such large numbers, the probability of human error in missing out few numbers or typing wrong numbers are high.

[0003] For example, in a scenario, a payee may himself erroneously provide an incorrect account number. The payee enters the incorrect account number and ends up sending funds to an unintended receiver. In another scenario, the payee provides the correct account number to a payer. However, the payer enters the payee account number incorrectly while sending funds to the payee.

[0004] In both the above-mentioned cases, the payer accidentally sends money to the unintended receiver. If the payer and the payee accounts are with a same bank, the process is usually faster to resolve the issue and reverse the transaction. However, if the payer and payee accounts are with different banks, reversing the transaction becomes a complicated process.

[0005] Further, in both the above-mentioned scenarios, it is required to intimate the unintended receiver and seek his permission for reversing the transaction. Without permission from the unintended receiver, the bank cannot reverse the transaction. If the unintended receiver disagrees, the payer of the money is left with option of legal recourse.

[0006] Therefore, to mitigate the chances of a wrong transaction, some banks ask the payer to enter the payee bank account number twice while adding the payee for money transfer. If both the payee bank account numbers entered do not match with each other, the payer is intimated of error in entering the payee bank account number. The drawback with this solution is that it fails if the payer receives the wrong bank account number for money transfer from the payee. The solution also fails if the payer enters the same wrong account number on both occasions. In both the above-mentioned scenarios, the payer ends up transferring funds to the unintended receiver.

[0007] In another existing art, the system for transaction displays a name of an account holder while adding the payee account number for a money transaction. The drawback with this solution is that it works only when the payee is the account holder in the same bank through which the sender is transferring the funds. This does not work when the bank account of the payer and the payee are in different bank accounts.

[0008] Further, in another existing art, the authentication of the money transaction is based on a penny test. The penny test involves performing a small money transfer first in the payee bank account and send the remaining amount after confirming with the payee. The drawback with this solution is unnecessary wastage of time and effort, as payers are required to place multiple transfer requests.

[0009] Furthermore, in another existing art, some banks utilize name matching software. When a payee’s name mentioned by the payer does not match with the account holder name of the account number entered, it is identified by the name matching software as an exception. All the requests that are identified by the name matching software as exceptions are processed manually. The process involves correspondence with the payee through emails, messages, phone calls, and the like. The drawback with this solution is that the usage of name matching software is not preventive as name matching is done after the payer places the request. Also, the technique does not facilitate a cent percent straight through processing as it involves exception processing. Also, it is expensive, as organizations are required to buy the name matching software.

[0010] Hence, there is a need for a system and method for simple, fool proof, and efficient technique for securing a financial transaction in order to address the aforementioned issues.

SUMMARY [0011] This summary is provided to introduce a selection of concepts, in a simple manner, which is further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the subject matter nor to determine the scope of the invention.

[0012] In accordance with a first embodiment of the present disclosure, a system and a method are disclosed for securing a financial transaction in a computing environment. The system includes one or more hardware processors, and a memory coupled to the one or more hardware processors. The memory includes a plurality of modules in the form of programmable instructions executable by the one or more hardware processors. The plurality of modules includes a fund transfer number (FTN) generator module configured to generate a fund transfer number (FTN) associated with each bank accounts. The FTN number is a unique alphanumeric combination associated with the bank accounts. Further, the plurality of modules comprises a request receiver module to receive a request for performing a financial transaction between a payer bank account and a payee bank account. The request comprises account data associated with the payee bank account. The account data comprises an account number, an IFSC code, an account type, and an account status and the like. The plurality of modules includes a payee data validation module configured to receive an FTN number corresponding to the payee bank account from a payer using a user interface of an application. The FTN number corresponding to the payee bank account is pre-generated and shared with the payer. Further, the data validation module is configured to validate the account data associated with the payee bank account and the received FTN number corresponding to the payee bank account based on the prestored account data associated with the payee bank account and the prestored FTN number corresponding to the payee bank account available in the Centralized database connected to the validation module of the Payer’s banking application. The validation further comprises validating payee bank account parameters such as account status and many other parameters at a real time. The plurality of modules includes a payment transaction module to perform the financial transaction between the payer bank account and the payee bank account after successful validation.

[0013] According to another embodiment of the present disclosure, a method for securing a financial transaction in a computing environment is disclosed. The method includes generating a fund transfer number (FTN) associated with each bank accounts. The FTN number is a unique alphanumeric combination associated with the bank accounts. The method further includes receiving a request for performing a financial transaction between a payer bank account and a payee bank account. The request comprises account data associated with a payee bank account. The account data comprises an account number, an IFSC code, an account type, an account status and the like. The method further comprises receiving an FTN number corresponding to the payee bank account from a payer using a user interface of an application. The FTN number corresponding to the payee bank account is pre-generated and shared with the payer. The method further includes validating the account data associated with the payee bank account and the received FTN number corresponding to the payee bank account based on the prestored account data associated with the payee bank account and the prestored FTN number corresponding to the payee bank account. The validation further comprises validating payee bank account parameters at a real time. Also, the method includes performing the financial transaction between the payer bank account and the payee bank account after successful validation.

[0014] To further clarify the advantages and features of the present invention, a more particular description of the invention will follow by reference to specific embodiments thereof, which are illustrated in the appended figures. It is to be appreciated that these figures depict only typical embodiments of the invention and are therefore not to be considered limiting in scope. The invention will be described and explained with additional specificity and detail with the appended figures.

BRIEF DESCRIPTION OF DRAWINGS

[0015] The disclosure will be described and explained with additional specificity and detail with the accompanying figures in which:

[0016] FIG. 1 is a block diagram illustrating an exemplary computing system capable of securing a financial transaction, in accordance with an embodiment of the present disclosure;

[0017] FIG 2 illustrates an exemplary method for securing a financial transaction in a computing environment, in accordance with an embodiment of the present disclosure;

[0018] FIG. 3 illustrates an exemplary method for creating combined code for each of bank accounts, in accordance with an embodiment of the present disclosure;

[0019] FIG. 4 illustrates an exemplary method for securing a financial transaction in a computing environment, in accordance with another embodiment of the present disclosure; [0020] FIG. 5 illustrates, an exemplary method of performing a transaction, in accordance with an embodiment of the present disclosure;

[0021] FIG. 6A-D illustrates exemplary user interfaces for sending one or more data associated with a bank account and for receiving one or more data associated with a bank account via a bank account specific email account issued by a bank, in accordance with an embodiment of the present disclosure;

[0022] FIG. 7 is a process flowchart illustrating an exemplary method for creating FTN number, in accordance with an embodiment of the present disclosure; and

[0023] FIG. 8 is a block diagram of an exemplary computing environment capable of securing a financial transaction using a centralized database, in accordance with an embodiment of the present disclosure.

[0024] Further, those skilled in the art will appreciate that elements in the figures are illustrated for simplicity and may not have necessarily been drawn to scale. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the figures by conventional symbols, and the figures may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the figures with details that will be readily apparent to those skilled in the art having the benefit of the description herein.

DETAILED DESCRIPTION OF THE INVENTION

[0025] For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the figures and specific language will be used to describe them. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended. Such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as would normally occur to those skilled in the art are to be construed as being within the scope of the present invention. It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be restrictive thereof.

[0026] The terms "comprise", "comprising", or any other variations thereof, are intended to cover a non-exclusive inclusion, such that one or more devices or modules or elements or structures or components preceded by "comprises... a" does not, without more constraints, preclude the existence of other devices, sub-systems, additional modules. Appearances of the phrase "in an embodiment", "in another embodiment" and similar language throughout this specification may, but not necessarily do, all refer to the same embodiment.

[0027] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this invention belongs. The system, methods, and examples provided herein are only illustrative and not intended to be limiting. Embodiments of the present invention will be described below in detail with reference to the accompanying figures.

[0028] A computer system (standalone, client or server computer system) configured by an application may constitute a “module” that is configured and operated to perform certain operations. In one embodiment, the “module” may be implemented mechanically or electronically, so a module may comprise dedicated circuitry or logic that is permanently configured (within a special-purpose processor) to perform certain operations. In another embodiment, a “module” may also comprise programmable logic or circuitry (as encompassed within a general-purpose processor or other programmable processor) that is temporarily configured by software to perform certain operations.

[0029] Accordingly, the term “module” should be understood to encompass a tangible entity, be that an entity that is physically constructed permanently configured (hardwired) or temporarily configured (programmed) to operate in a certain manner and/or to perform certain operations described herein.

[0030] The present disclosure provides a system and method for securing a financial transaction in a computing environment after validating a payee bank account through a fund transfer number (FTN number) associated with the payee bank account. The present method is applicable to both offline and online fund transfer requests.

[0031] At the time of processing fund transfer requests that are made offline through cheques and the like, banking system may take certain measures to validate payee’s account details provided by payers. Specification of Payee Account details along with the FTN number associated with it helps the banking systems in validating the payee account number by cross verifying the account number with the details available in their internal database. Any mismatch in the specified payee account number and the FTN numbers shall result in rejection of the transaction making the offline fund transfers processing more robust and fool proof. [0032] FIG. 1 is a block diagram illustrating an exemplary computing environment 10 for securing a financial transaction, in accordance with an embodiment of the present disclosure. The exemplary computing environment 10 comprises one or more user device(s) 200 in communication with a system 100 via a network. The network includes a Wi-Fi connection, a Hotspot connection, a Bluetooth connection, a local area network and the like. The one or more user device(s) 200 is either a device held by a payer sending money from a payer bank account or a device held by a payee receiving money in a payee bank account. The one or more user device(s) 200 includes a smart phone, a laptop, a desktop, and the like. The one or more user device(s) 200 accesses one or more modules of the system 100 via a user interface for straight through processing of the payment amount in an electronic money transfer transaction process.

[0033] The system 100 includes one or more hardware processor(s) 145, an internal database 140, and a memory 101. The one or more hardware processor(s) 145 are communicatively coupled to the memory 101 and the internal database 140 via a system bus such as a bus 135 or a similar mechanism. The one or more hardware processor(s) 145, as used herein, is comprised of any type of computational circuit, such as but not limited to, a microprocessor unit, microcontroller, complex instruction set computing microprocessor unit, reduced instruction set computing microprocessor unit, very long instruction word microprocessor unit, explicitly parallel instruction computing microprocessor unit, graphics processing unit, digital signal processing unit, or any other type of processing circuit. The one or more hardware processor(s) 145 also includes embedded controllers such as generic or programmable logic devices or arrays, application specific integrated circuits, single-chip computers, and the like.

[0034] The memory 101 is non-transitory volatile memory or non-volatile memory. The memory 101 is coupled to communicate with the one or more hardware processor(s) 145, such as being a computer-readable storage medium. The one or more hardware processor(s) 145 execute machine-readable instructions and/or source code stored in the memory 101. A variety of machine-readable instructions are stored in, and accessed from, the memory 101. The memory 101 includes any suitable elements for storing data and machine-readable instructions, such as read only memory, random access memory, erasable programmable read only memory, electrically erasable programmable read only memory, a hard drive, a removable media drive for handling compact disks, digital video disks, diskettes, magnetic tape cartridges, memory cards, and the like. In the present embodiment, the memory 101 includes a plurality of modules stored in the form of machine -readable instructions on any of the above-mentioned storage media and may be in communication with and executed by the one or more hardware processor(s) 145.

[0035] The memory 101 includes a plurality of modules in the form of programmable instructions executable by the one or more hardware processors 145. The plurality of modules includes a fund transfer number generator module 105, a request receiver module 110 , , a payee data validation module 115, and a payment transaction module 120.

[0036] The internal database 140 stores information relating to the system 100. The internal database 140 is, for example, a structured query language (SQL) data store. The internal database 140 is configured as database implemented in the system 100. The internal database 140, according to another embodiment of the present disclosure, is a location on a file system directly accessible by the plurality of modules.

[0037] The fund transfer number generator module 105 is configured for generating a fund transfer number (FTN) associated with each bank accounts. The FTN number is a unique alphanumeric or alphanumeric with or without ‘special characters’ combination associated with the bank accounts. Although, an alphanumeric number would be sufficient, creating the FTN numbers with a combination of alphabets, numerals and special characters would make the FTN number very robust. This would ensure the highest and the best complexity of the FTN number.

[0038] The request receiver module 110 is configured to receive a request for performing a financial transaction between a payer bank account and a payee bank account. The request comprises account data associated with the payee bank account. The account data comprises an account number, an IFSC code, an account type, an account status and the like. The request receiver module 110 is further configured to receive a message comprising payee account data and a message identifier associated with the payer bank account from a payee. The message is in read only format. The message may be an online banking request, an electronic email, a short messaging service (SMS) or in any other form.

[0039] The data validation module 115 is configured to receive an FTN number corresponding to the payee bank account from a payer using a user interface of an application. The FTN number corresponding to the payee bank account is pre-generated and shared with the payer. Further, the data validation module 115 is configured to validate the account data associated with the payee bank account and the received FTN number corresponding to the payee bank account based on the prestored account data associated with the payee bank account and the prestored FTN number corresponding to the payee bank account. The validation further comprises validating payee bank account parameters such as account status and many other parameters at a real time. The account status may be inactive, active, account permitted to receive funds or not and the like. The FTN number is a unique alphanumeric or alphanumeric with or without ‘special characters’ combination associated with the payee bank account. Although, an alphanumeric number would be sufficient, creating the FTN numbers with a combination of alphabets, numerals and special characters would make the FTN number very robust. This would ensure the highest and the best complexity of the FTN number. The validation is performed by checking if the FTN number received is associated with the payee bank account number entered. If the FTN number received is found associated with the payee bank account number, it is a successful validation, else the validation fails. The data validation module 115 is further configured for rejecting the request for performing the financial transaction between the payer bank account and the payee bank account if the validation fails. Based on the logic that the probability of the remitter or originator providing an incorrect/wrong account number that is pertaining to a different person other than the intended payee and the FTN number that is pertaining to that wrong account number of the unintended payee is Absolutely Nil.

[0040] The data validation module 115 is further configured to validate the payee account data associated with the payee bank account and the message identifier associated with the payer bank account based on the prestored payee account data and the prestored message identifier.

[0041] In an exemplary embodiment, a central bank or authorized entities of the countries create a unique FTN number for each of bank accounts, including the payer bank account, and the payee bank account. Each of the FTN number is a combination of numbers, alphabets, and special characters. In an exemplary embodiment, the length of the FTN number varies from a minimum of five to ten characters, such as 9@b$2#, z%5k3@ lj, and the like.

[0042] In the exemplary embodiment, the central bank or the authorized entities in India, such as Reserve Bank of India (RBI) or NPCI (National Payments Corporation of India) create a centralized database with each of the one or more bank accounts belonging to a list of the banks in India consolidated along with one or more details associated with each of the one or more account numbers, such as an account number, an FTN number, an IFSC Codes, an account type, an account status, and the like. The FTN number is made mandatory to add a payee for a money transaction. The payer uses the FTN number of the payee to make a payment to the intended payee, without any error. Creation of centralized database facilitates pre-validation of the Payee account details before placing the fund transfer request through an interface between the centralized database and the application used by the Payer to initiate the fund transfer request like the online banking platform.

[0043] In another exemplary embodiment, the FTN number is further combined with the IFSC code associated with the payee bank account. The IFSC code combined with the FTN number generates a unique IFSC code or a combination code associated with the payee bank account. Thereafter, the payee data validation module 115 validates the payee bank account via unique IFSC code or combination code associated with the payee bank account.

[0044] The payment transaction module 120 is configured to perform the financial transaction between the payer bank account and the payee bank account after successful validation . The financial transaction comprises fund transfer, addition of a beneficiary, and updating account data. Thereafter, a notification updating status of the fund transfer is displayed on the user interface.

[0045] Further, the payment transaction module 120 is further configured to perform the financial transaction between the payer bank account and the payee bank account after successful validation.

[0046] Further, in an additional embodiment, the payer account is associated with a payer email account associated with the mailbox available in his online banking platform and the like, and the payee bank account is associated with a payee email account associated with the mailbox available in his online banking platform and the like. The account data associated with the payee bank account is sent from the payee email account to the payer email account.

[0047] Each of the one or more bank accounts are issued the bank account specific email account, such as abc.xyz@pqrbank.com be an email ID associated with the payee bank account. Here ‘ABC XYZ’ depicts a bank account holder’s name for the payee bank account. The ‘PQR’ depicts a name of the bank to which the payee bank account belongs to. The payee bank account sends the account data associated with the payee bank account through his email account linked to his bank account or mailbox available in his online banking platform. This is achieved by clicking a ‘Send Payee Details’ option available in his Online banking platform.

[0048] In an exemplary embodiment, the account data associated with the payee bank account sent to the email ID associated with the payer bank account is in a read only format. The account data in the read only format remains untampered.

[0049] Further, in an exemplary embodiment, the bank account specific email account accepts one or more messages sent from one or more other bank account specific email accounts. The bank account specific email accounts do not accept any emails or messages sent through any email accounts other than that associated with the one or more bank accounts.

[0050] The payer opens the email account associated with the payer bank account available in his Online banking platform, verifies the payee details, and clicks an ‘Add Payee’ or ‘Fund Transfer’ option to add the payee to a list of his beneficiaries. However, we specify the payee account details this method would be applicable. Further, the Online banking platform captures the details available in the message and adds the payee to the list of beneficiaries. The exemplary embodiment is applicable to all different modes of domestic and cross border fund transfers.

[0051] Those of ordinary skilled in the art will appreciate that the hardware depicted in FIG 1 may vary for particular implementations. For example, other peripheral devices such as an optical disk drive and the like, Local Area Network (LAN), Wide Area Network (WAN), Wireless (e.g., Wi-Fi) adapter, graphics adapter, disk controller, input/output (I/O) adapter also used in addition or in place of the hardware depicted. The depicted example is provided for the purpose of explanation only and is not meant to imply architectural limitations with respect to the present disclosure.

[0052] Those skilled in the art will recognize that, for simplicity and clarity, the full structure and operation of all data processing systems suitable for use with the present disclosure is not being depicted or described herein. Instead, only so much of the system 100 for document management of the discovery process, as is unique to the present disclosure or necessary for an understanding of the present disclosure is depicted and described. The remainder of the construction and operation of the system 100 may conform to any of the various current implementation and practices known in the art. [0053] FIG 2 illustrates an exemplary method 20 for securing a financial transaction in a computing environment, in accordance with an embodiment of the present disclosure. At step 205, a fund transfer number (FTN) associated with each bank accounts is generated. The FTN number is a unique alphanumeric or alphanumeric with or without ‘special characters’ combination associated with the bank accounts. At step 210, a request for performing a financial transaction between a payer bank account and a payee bank account is received. The request comprises account data associated with a payee bank account. The account data comprises an account number, an IFSC code, an account type, an account status and the like. At step 215, an FTN number corresponding to the payee bank account is received from a payer using a user interface of a banking application. The FTN number corresponding to the payee bank account is pre-generated and shared with the payer. At step 220, the account data associated with the payee bank account and the received FTN number corresponding to the bank account is validated based on the prestored account data associated with the payee bank account and the prestored FTN number corresponding to the payee bank account available in the Centralized database (as specified in FIG. 7 & shown in FIG. 8) connected to the validation module of the Payer’s banking application. The validation further comprises validating payee bank account parameters such as account status and the like at a real time. The account parameters are validated to ensure that the transaction would not get rejected after it passes the validation status. This is because it ensures cent percent STP and cent percent accuracy. Therefore, the payee’s account data are validated thoroughly before the transaction is placed. In some cases, transactions may be declined for other reasons other than the status of the account. For example, if lien is marked on the account, or if account has been frozen temporarily, or if failure due to account irregularity, or if failure due to account type (for example, some types of accounts are not authorized to receive funds) and the like. An account can be an ACTIVE account and still may not be eligible to receive funds due to such reasons or some restrictions imposed by the banks at that point of time.

[0054] At step 225, the financial transaction between the payer bank account and the payee bank account is performed after successful validation. The financial transaction comprises fund transfer, addition of a beneficiary, and updating account data.The method 20 further includes rejecting the request for performing the financial transaction between the payer bank account and the payee bank account if the validation fails.

[0055] In an embodiment, the FTN number is further combined with the IFSC code associated with the payee bank account to generate a combined code associated with the payee bank account. The payee bank account is validated based the combined code associated with the payee bank account.

[0056] The method 20 further includes receiving a message comprising payee account data and a message identifier associated with the payer bank account from a payee’s online banking mailbox, wherein the message is in read only format. The method 20 further includes validating the payee account data associated with the payee bank account and the message identifier associated with the payer bank account based on the prestored payee account data and the prestored message identifier. Further, the method 20 include performing the financial transaction between the payer bank account and the payee bank account after successful validation.

[0057] In an embodiment, the FTN number is a unique alphanumeric or alphanumeric with or without ‘special characters’ combination associated with the payee bank account. The FTN number is a combination of numbers, alphabets, and special characters. In an exemplary embodiment, the length of the FTN number varies from a minimum of five to ten characters, such as 9@b$2#, z%5k3@lj, and the like. The validation is performed by checking if the FTN number received is associated with the payee bank account number entered. If the FTN number received is found associated with the payee bank account number, it is a successful validation, else the validation fails. The probability of the remitter or originator providing an incorrect/wrong account number that is pertaining to a different person other than the intended payee and the FTN number that is pertaining to that wrong account number of the unintended payee is Absolutely Nil.

[0058] In another exemplary embodiment, the FTN number is further combined with the IFSC code associated with the payee bank account to generate a unique IFSC code associated with the payee bank account. Thereafter, the payee bank account is validated via the unique IFSC code associated with the payee bank account.

[0059] Thereafter, a notification updating status of the fund transfer is displayed on the user interface. In this embodiment, the systems 100 need not provide the IFSC code as the centralized database has a field for IFSC codes.

[0060] Further, in an exemplary embodiment, the payer’s bank email account is associated with the mailbox available in his online banking platform. The account data associated with a payee bank account is sent from the payee email account to the payer email account. [0061] FIG. 3 illustrates an exemplary method 30 for creating a combined code for each of bank accounts, in accordance with an embodiment of the present disclosure. Each of the FTN number is a combination of numbers, alphabets, and special characters. In an exemplary embodiment, the length of the FTN number varies from a minimum of five to ten characters, such as 9@b$2#, z%5k3@ lj, and the like.

[0062] At step 305, an FTN number in the form of a unique alphanumeric or alphanumeric with or without ‘special characters’ combination associated with each of the bank account is created , by a central bank or authorized entities. At step 310, a bank account is added, or payment amount is transacted to a bank account by mandating the provision of the FTN number. At step 315, a payer bank receives account data associated with a payee bank account. The account data comprises an account number, an IFSC code, an account type, an account status and the like. At step 320, the payer bank validates the account data with the FTN number associated with the payee bank account. At step 325, after successful validation, the payer bank adds the payee bank account or transacts the payment amount in the payee bank account

[0063] In the further exemplary embodiment, the method 30 is implemented without creating a centralized database. The central bank or the authorized entities in India, such as Reserve Bank of India (RBI) or NPCI (National Payments Corporation of India) generates FTN number for each of the one or more bank accounts belonging to a list of the banks and stores in one or more database of the list of the banks. The FTN number is made mandatory to add a payee for a money transaction. The payer uses the FTN number of the payee to make a payment to the intended payee, without any error Further, the payer user inputs codes if there are any such as IFSC codes in India. Eater, the payer user adds the payee or remits the funds. After this, the payee bank receives this request. The system 100 credits the funds to the payee’s account number after matching the payee’s account number and FTN number provided by the payer user with those available in their internal database 140. If the details match, the funds are credited to the payee’s account. If the details do not match, the funds are not credited to the payee’s account. This post-validation of payee’s account details by payee’s bank (which are provided by the payer while initiating the fund transfer request) ensures cent percent accuracy.

[0064] In order to issue the FTN number, banks access the centralized database maintained by banks such as RBI/NPCI through an interface to generate the FTN numbers on real time while opening a new account by providing all the required fields such as account numbers, FTN numbers, IFSC Codes, Account type, Account status and the like.

[0065] The FTN number generated is given to the account holder and added to the account creation process in their internal systems. This not only eliminates human intervention at any stage of issuance of FTN numbers. Also, this procedure keeps the centralized database updated with all the account numbers and FTN numbers. This procedure perfectly eliminates the chance of creating duplicate FTN numbers.

[0066] In this embodiment, it is mandatory to update the IFSC code while adding or remitting funds as IFSC code is required to route the payments to that particular bank and branch. In any embodiment, the issuing authority of the FTN number should be one single source such as for example, RBI or NPCI in India. This is to maintain the uniqueness of the FTN number.

[0067] FIG. 4 illustrates an exemplary method 40 for straight through processing of the payment amount, in accordance with another embodiment of the present disclosure. In this embodiment, the IFSC code is combined with the FTN number to generate a combination code associated with the payee bank account. Thereafter, the payee bank account is validated via the combination code associated with the payee bank account. Specifically, the FTN number so generated from the centralized database is added to the IFSC code of that particular branch. This is to make the IFSC code unique.

[0068] At step 405, an FTN number in the form of a unique alphanumeric or alphanumeric with or without ‘special characters’ combination associated with each of the bank account is created by the central bank or the authorized entities. At step 410, for each of the bank account, the FTN number is combined with the IFSC code to generate a combination code. At step 415, a bank account is added, or payment amount is transacted to a bank account by mandating the provision of the FTN number. At step 420, a payer bank account receives the account data associated with a payee bank account. At step 425, the payer bank account validates the account data with the combination code associated with the payee bank account. At step 430, after successful validation, the payer bank account adds the payee bank account or transacts a payment amount in the payee bank account, this ensures cent percent accuracy and cent percent straight through processing (STP) of the payment amount. [0069] In an embodiment, the payer user inputs the payee account number. Further, the payer user inputs the combination code which is the combination of the IFSC code and the FTN number of the account. Further, the payer user adds the payee or remits the funds, this ensures cent percent accuracy and cent percent straight through processing (STP) of the payment amount.

[0070] The system 100 credits the funds to the payee account after matching the payee’s account number and the combination code provided by the payer user with that available in their database. If the details match, the funds are credited to the payee’s account. If the details do not match, then the funds are not credited to the payee’s account.

[0071] FIG. 5 illustrates, an exemplary method 50 of performing a transaction, in accordance with an embodiment of the present disclosure. Each of one or more bank accounts from one or more banks are issued a bank account specific email account, such as abc.xyz@pqrbank.com . Here, ‘ABC XYZ’ depicts a bank account holder’s name for the bank account, and ‘PQR’ depicts a domain name of the bank to which the bank account belongs to.

[0072] At step 505, each of the one or more banks generate a message identifier associated with each of the one or more bank accounts. This message identifier may be similar to e-mail ID for example, abc@xyzbank.com. At step 510, payees send their account details through their mailbox using a ‘Send Payee Details’ option available in the respective online banking platform by quoting the Message identifier of the payer user. For example, rekha.r@pqrbank.com. The electronic message with account details are in read only format which cannot be tampered with. In addition, these mailboxes available in the banking online platforms accept only those electronic messages sent through the mailboxes of other banking online platforms. In simple terms, these mailboxes should not accept any of the mails or the electronic messages sent through any medium other than banks. At step 515, the payer user opens the mailbox available in his online banking platform, verifies the account details of the payee and clicks ‘Add Payee’ option to add the payee to his list of beneficiaries. This ensures cent percent accuracy and cent percent straight through processing (STP) of the payment amount. Alternatively, at step 520, payer can transfer funds to the payee bank account by clicking on ‘Transfer Funds’ option without adding the payee as a Beneficiary in his account. The payer uses either of these options, ‘Add Payee’ or ‘Transfer Funds’ to transfer funds according to the procedures of his bank as depicted in FIG. 6C. [0073] Recalibrated Online banking platforms auto captures the account details available in the electronic message and adds the payee to the list of payees. This method 50 can be easily applied to all different modes of domestic & cross border fund transfers/remittances (both inward and outward). This method 50 of sharing account details has certain benefits. The payee need not share his bank account details through any third-party applications. Sharing of account details is happening only in between the banks online banking platforms.

[0074] In case if the payee sends the electronic message erroneously to a wrong mailbox of an unknown account holder, the method 50 does not cause any risk as this is only sharing of account details. Still, if the banks think it is necessary to have a control on this, the banks can add a feature (optional). At the time of sending the account details to the payer user, the payee generates a passcode or secrete code, which he needs to convey to the payer user for him to unlock the message and proceed with ‘Add Payee’ as specified above. This additional layer of security perfectly eliminates the risk of sharing account details with unknown people. This additional layer can be set up either as an optional or mandatory procedure. This additional layer ensures cent percent accuracy and cent percent straight through processing (STP) of the payment amount. This is shown in detail in FIG. 6B.

[0075] FIG. 6A-D illustrates exemplary user interfaces 60a, 60b, 60c, 60d, 60e, 60f, 60g, and 60h respectively for exchanging data associated with a bank account via a bank account specific email account issued by the bank.

[0076] According to FIG. 6A, the exemplary user interface 60a depicts sending data associated with a first bank account from a first bank specific email account 1 named as ‘A’s bank mailbox’ to a second bank specific email account with an email ID 4 named as ‘b@xyzbank.com’. The data 2 associated with the first bank account sent includes a bank name, which is ‘ABC Bank’ in the exemplary depiction. The data 2 associated with the first bank account sent includes a bank account number, which is ‘123456789’ in the exemplary depiction. The data 2 associated with a first bank account sent includes an IFSC code, which is ‘ABC012345’ in the exemplary depiction. The data 2 associated with the first bank account sent includes Bank Branch, which is ‘Madinaguda’ in the exemplary depiction. A button 3 named as ‘Send Payee Details’ is clicked, and the data associated with the first bank account is sent to ‘b@xyzbank.com’.

[0077] Therefore, a payee bank account sends the data associated with the payee bank account through their email account by clicking a ‘Send Payee Details’ option available in his online banking platform displayed on the user interface after entering the email ID associated with the payer bank account.

[0078] In an exemplary embodiment, the electronic message is in a read only format. The account data in the read only format remains untampered.

[0079] The exemplary user interface 60b depicts adding the first bank account as payee bank account by the second bank account after receiving the data 7 associated with the first bank account in a second bank specific email account 5 named as ‘B’s bank mailbox’ from the first bank specific email account with the email ID 6 named as ‘a@abcbank.com’. The data 7 associated with the first bank account received includes a bank name, which is ‘ABC Bank’ in the exemplary depiction. The data 7 associated with the first bank account received includes the bank account number, which is ‘123456789’ in the exemplary depiction. The data 7 associated with the first bank account received includes the IFSC code, which is ‘ABC012345’ in the exemplary depiction. The data 2 associated with the first bank account received includes bank branch, which is ‘Madinaguda’ in the exemplary depiction. A button 8 named as ‘Add Payee’ is clicked and the first bank account is added as a payee by the second bank account.

[0080] Therefore, the data associated with the payee bank account is received by the payer account through an electronic message and displayed in the mailbox relating to Payer’s bank email account. Further, by clicking the ‘Add Payee’ option available on the user interface, the payee bank account is added by the payer bank account to further transfer the payment amount in the payee bank account.

[0081] Further, in an exemplary embodiment, the bank account specific email account accepts one or more messages sent from one or more other bank account specific email accounts. The bank account specific email accounts do not accept any emails or messages sent through any email accounts other than that associated with one or more bank accounts.

[0082] FIG.6B illustrates exemplary user interfaces 60c and 60d respectively for exchanging data associated with a bank account via a bank account specific email account issued by the bank using additional control passcode. In an embodiment, when the payee 1 specifies the bank email ID of the payer 5, the system 100 sends the payee’s account data 2 to the payer 5 and generates a passcode 10 if payee 1 opts to have additional layer of security to prevent his account data from being erroneously shared with unintended people. The payee 1 conveys this passcode 10 to the payer 5. The payer 5 is then able to unlock the electronic message only through the passcode 10 received from the payee 1. This method prevents unintended recipients from getting to know the bank account data, as they would not have the passcode 10 to unlock the message.

[0083] FIG. 6C illustrates exemplary user interfaces 60e and 60f respectively for exchanging data associated with a bank account via a bank account specific email account issued by the bank, in accordance with an embodiment of the present disclosure. According to FIG. 6C, if the verification is successful, the system 100 allows the payer 5 to transfer funds with or without adding the payee 1. Else, the system 10 displays verification failed message and the payer 5 is prevented from transferring funds. The payer 5 can transfer funds to the payee bank account 6 by clicking on ‘Transfer Funds’ option 9 without adding the payee 1 as a Beneficiary in his account. The payer 5 uses either of these options, ‘Add Payee’ 8 or ‘Transfer Funds’ 9 to transfer funds according to the procedures of his bank.

[0084] According to FIG. 6D, an exemplary user interface 60g and 60h depicting a process of authentication of funds to be credited to user bank account 11 is provided. The banks provide an option to all the account holders. This option is to give an authority to the account holders or the payees to decide who can park funds into their account 11. This option provides as an additional layer 13 of protection to the account holders empowering them to restrict the unauthorized funds from being credited into their account 11 and protects them from legal issues. As shown, if an account holders opts 12 to authorize all the fund transfers to his account 11, the system 100 obtains his authorization before crediting funds into his account 11. Else, the amount shall be held till the time it is authorized by the account holder. If the ‘fund transfer’ is not authorized, funds would be returned back to the remitter. This can be given as an option 12 to the account holders and this option 12 may be mandatorily implemented by the RBI or other central banks. This is purely a call need to be taken by the RBI or central banks. The RBI or the central banks needs to decide the list of fields to be placed along with the account numbers in the centralized database based on the type of rejections occurring. Hence, the decision is taken by the RBI to finalize which additional field or fields have to be there in the centralized database. The provision of preauthorization option 12 or a onetime approval option 17 to the account holders help in reduction of work relating to the authorization of recurring credits. For example, funds received by ‘X’ payer 14 for those products are returned by the account holder. This process is similar to addition of a beneficiary with one time entry. Likewise, an authorization privilege is provided to a payer or remitter with a onetime authorization 17. In another exemplary embodiment, an authorization 16 may be given by the account holder after his bank requests him to authorize a payment when he receives a fund. In another exemplary embodiment, a preauthorization 18 is given even before receiving a fund from the payer. For example, a payee has provided his account details to the payer and preauthorize his account from which he is going to receive the funds. In such case, the payer uses another account which is not preauthorized by the payee, the transaction can still be authorized by the payee as suggested in Authorized Method 16. The cross validation of the payee details with the centralized database also checks for other fields which would decide whether a payment request has to be approved or rejected.

[0085] FIG. 7 is a process flowchart illustrating an exemplary method for creating FTN number, in accordance with an embodiment of the present disclosure. At step 702, a centralized database is created by national banking authorities such as reserve bank or NPCI. At step 704, access to the centralized database is given through an API. At step 706, all the necessary information such as account number, IFSC Code, name of the A/C holder and the like are updated into the centralized database through the API and the unique Fund Transfer Number (FTN) is generated. Basically, all the banks need to provide all the information whichever are required to validate the accounts while authorizing the accounts. The process of creation of the FTN numbers for all the accounts by one single entity such as RBI or NPCI ensures the uniqueness of the FTN numbers. In an alternate embodiment, banks can also create FTN numbers on their own. However, entities such as RBI or NCPI need to formulate proper guidelines to ensure the FTN numbers created by individual banks would not overlap. This is an additional precaution.

[0086] FIG. 8 is a block diagram of an exemplary computing environment 800 capable of securing a financial transaction, in accordance with an embodiment of the present disclosure. The computing environment 800 comprises a computing system 100, such as those shown in FIG. 1, a centralized database 824, a sender side and a receiver side. The sender side comprises a sender 808 capable of financially transacting with a recipient 818 using at least one of a remote banking 802, ATM 804, net banking 806 or any other means. The sender 808 performs the financial transaction using a sender side processing system 810. The sender side processing system 810 allows for processing of data from the sender 808 and transmitting the data to the computing system 100 via a network 822. Similarly, the recipient side comprises a recipient 818, a remote banking 812, ATM 814, net banking 816 or any other means. The recipient 818 receives the financial transaction using a recipient side processing system 820. The recipient side processing system 820 allows for processing of data from the recipient 818 and transmitting the data to the computing system 100 via the network 822. The creation and the role of the centralized database 824 is described above with respect to FIG. 1, FIG. 2 and FIG 3.

[0087] Various embodiments of the present disclosure provide a technical solution to eliminate chances of fund transfer to an unintended user erroneously during a payment process from a payer to a payee. Validating a bank account number with FTN number, uniquely generated for the bank account, eliminates any risk of error in a transaction at the pre payment stage itself there by ensures cent percent accuracy and facilitates cent percent straight through processing (STP) of fund transfer.

[0088] The present disclosure prevents fund transfer to an unintended receiver due to incorrect account number, incorrect IFSC number, and incorrect account holder name, and due to any other account irregularity. Conclusively, the present disclosure controls unauthorized credits to a great extent in any fund transfer process.

[0089] Also, the present disclosure eliminates all the drudgery involved in matching payee names by the bank employees. The present disclosure eliminates all the exception processing done by banks on fund transfers when there is a mismatch in payee names as all the wrong entries associated with payee account numbers are identified at the prepayment stage itself.

[0090] Further, the FTN number generated is unique to a bank account and added to the account creation process in their internal systems. Therefore, any human intervention at any stage of issuance of FTN numbers is eliminated. Also, this procedure keeps the centralized database updated with all the account numbers and associated FTN numbers. The procedure perfectly eliminates the chance of creating duplicate FTN numbers.

[0091] Furthermore, an additional embodiment of present disclosure facilitates associating each of the bank account with an email account and facilitating sending data associated with a first bank account, to an email account associated with a second bank account. The data associated with a first bank includes bank account details, such as an account number, an FTN number, an account status, an IFSC code, and the like. The eliminates chances of sharing any erroneous data while the payee sharing bank account details to a payer. This method perfectly eliminates all manual intervention happening in the form of adding the payee details or to transfer funds to a payee. In addition, for banks, the disclosure eliminates all the drudgery involved in validating the payee details before crediting the funds to the payee account. The method provides straight through processing of fund to an intended payee account without any fault. This methods eliminates the need to enter the payee details manually to Add a Payee or to transfer funds to a Payee.

[0092] In above mentioned embodiment, the payee does not require to share his bank account details through any third-party applications, rather, sharing of account details is done only in between the banks’ online banking platforms.

[0093] Further, if the payee sends the message erroneously to a wrong email account of an unknown account holder, it does not cause any risk as it is only sharing details of the payee bank account.

[0094] However, in another exemplary embodiment, if the banks need to have control on the above situation, an optional feature is provided. At the time of sending the account details to the payer, the payee generates a passcode or a secret code, which he conveys to the payer. The payer requires to enter the passcode or the secret code to unlock the message and proceed with ‘Add Payee’. The additional layer of security eliminates the risk of sharing account details with unknown people.

[0095] The present disclosure nullifies the probability of the remitter or originator providing an incorrect/wrong account number that is pertaining to a different person other than the intended payee and the FTN number that is pertaining to that wrong account number of the unintended payee. This is due to the unique FTN number which is a complex combination of numbers, alphabets and special characters, such as for example, ‘9@b$2#’, ‘z%5k3@lj’. In simple terms, the probability of the remitter or originator providing an incorrect/wrong account number that is pertaining to a different person other than the intended payee and the FTN number that is pertaining to that wrong account number of the unintended payee is Absolutely Nil. All the methods described above are based on this concept. This disclosure hence solves critical issues associated with the fund transfers in the simplest possible manner.

[0096] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the disclosure and are not intended to be restrictive thereof.

[0097] While specific language has been used to describe the disclosure, any limitations arising on account of the same are not intended. As would be apparent to a person skilled in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.

[0098] The figures and the foregoing description give examples of embodiments. Those skilled in the art will appreciate that one or more of the described elements may well be combined into a single functional element. Alternatively, certain elements may be split into multiple functional elements. Elements from one embodiment may be added to another embodiment. For example, the order of processes described herein may be changed and are not limited to the manner described herein. Moreover, the actions of any flow diagram need not be implemented in the order shown; nor do all of the acts need to be necessarily performed. Also, those acts that are not dependent on other acts may be performed in parallel with the other acts. The scope of embodiments is by no means limited by these specific examples.