Description:FIELD OF THE INVENTION

[0001] The present invention generally relates to financial transactions and more particularly relates to a system and a method for performing secured financial transactions between multiple financial entities.
BACKGROUND

[0002] In today's digital age, financial transactions have become an integral part of our daily lives. Whether it's registering for events, subscribing to online courses, or purchasing goods and services, we often find ourselves making payments through various platforms. However, a recurring issue arises when users are required to make full payments in one go, as many institutes and organizations do not accept partial payments. This poses a challenge when users do not have sufficient funds in their main account, particularly a bank account. This may lead to the need for transferring funds from one or multiple other bank accounts to the main account.
[0003] The inconvenience of juggling multiple transactions across different accounts not only complicates the payment process but also requires users to carry various financial account details.
[0004] Figure 1 illustrates an exemplary scenario depicting an absence of secured interoperability between multiple financial institutes, according to the prior art. The interoperability may be indicated as the inability of financial institutes to communicate with each other even though belonging to a single user. For instance, a user ‘U’ wants to register for an event with a merchant ‘M’, which requires a full payment upfront to be paid by the user to the merchant. If the user's main account with an institute, preferably a financial institute ‘A’ such as a bank, lacks the necessary funds, then the user must explore alternative accounts to cover the shortfall. This may involve transferring funds from one or multiple accounts, say another account with another financial institute ‘B’ which may be a time-consuming and error-prone process. Moreover, it necessitates the user to remember multiple login credentials and navigate through various banking interfaces, adding unnecessary complexity to an otherwise straightforward transaction.
[0005] Furthermore, carrying multiple financial cards to facilitate transactions from different accounts can be cumbersome and increases the risk of misplacing or losing these cards. The user may find it inconvenient to carry numerous cards, especially in situations where digital wallets and mobile payment solutions are becoming increasingly prevalent.
[0006] The inconvenience of managing multiple transactions and carrying numerous financial cards when making full payments across various accounts is a problem faced by many users. However, with the advancement of technology and the willingness of institutes, organizations, and financial institutions to collaborate, solutions must be developed to simplify these transactions.
[0007] As the digital landscape continues to evolve, it is crucial for stakeholders to work together to create a seamless payment ecosystem. Therefore, there exists a need to create interoperability among different financial institutes to seamlessly transfer payments in one go, seamlessly and with minimum hassle.
[0008] Further, it is also important to ensure that the interoperability among different financial institutes is secured and wrapped with authentication tools. The existing technologies such as a virtual wallet, and unified payments may connect multiple accounts of the various financial institutes, however, fail to provide a secure way to exchange information, and payments, between the financial institutes periodically.
[0009] Therefore, there exists a need to find a solution for the above-mentioned technical problems.
SUMMARY

[0010] This summary is provided to introduce a selection of concepts, in a simplified format, that are further described in the detailed description of the invention. This summary is neither intended to identify key or essential inventive concepts of the invention and nor is it intended for determining the scope of the invention.
[0011] According to one embodiment of the present disclosure, a method for performing secured financial transaction between a customer account and a merchant is disclosed. The method includes receiving, by a first server, a request received from an entity associated with the merchant, wherein the request indicates an amount to be deducted for the financial transaction from the customer account associated with the first server. The method includes determining, by the first server, if the requested amount is more than a current financial transaction limit associated with the customer account. The method includes sending, by the first server, at least one communication and an authentication token to a linked account associated with a second server different from the first server, upon determining that the requested amount is more than the current financial transaction limit, the at least one communication comprising a request for deduction of a balance amount from the linked account, wherein the balance amount is determined based on a comparison of the requested amount and the current financial transaction limit associated with the customer account. The method includes receiving, by the first server, the balance amount in the associated customer account from the linked account in response to sending the at least one communication and upon successful validation of the authentication token; and performing, by the first server, the financial transaction from the customer account to the entity associated with the merchant based on the current financial transaction limit and the balance amount.
[0012] According to one embodiment of the present disclosure, a system for performing secured financial transaction between a customer account and a merchant is disclosed. The system includes a first server comprising a memory and at least one processor in communication with the memory. The at least one processor is configured to receive a request received from an entity associated with the merchant, wherein the request indicates an amount to be deducted for the financial transaction from the customer account associated with the first server. The at least one processor is configured to determine if the requested amount is more than a current financial transaction limit associated with the customer account. The at least one processor is configured to send at least one communication and an authentication token to a linked account associated with a second server different from the first server, upon determining that the requested amount is more than the current financial transaction limit, the at least one communication comprising a request for deduction of a balance amount from the linked account, wherein the balance amount is determined based on a comparison of the requested amount and the current financial transaction limit associated with the customer account. The at least one processor is configured to receive the balance amount in the associated customer account from the linked account in response to sending the at least one communication and upon successful validation of the authentication token; and perform the financial transaction from the customer account to the entity associated with the merchant based on the current financial transaction limit and the balance amount.
[0013] To further clarify the advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which are illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of its scope. The invention will be described and explained with additional specificity and detail in the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

[0014] These and other features, aspects, and advantages of the present invention will become better understood when the following detailed description is read with reference to the accompanying drawings in which like characters represent like parts throughout the drawings, wherein:
[0015] Figure 1 illustrates an exemplary scenario depicting an absence of secured interoperability between multiple financial institutes, according to the prior art.
[0016] Figure 2a illustrates a schematic block diagram depicting an environment for the implementation of a system for performing secured financial transactions between a customer account associated with a first server and a merchant, according to an embodiment of the present invention;
[0017] Figure 2b illustrates another schematic detailed block diagram of modules/software components of the system, according to an embodiment of the present invention;
[0018] Figure 3a illustrates a process flow of a method for linking the linked account with the customer account, according to an embodiment of the present invention;
[0019] Figure 3b illustrates a process flow of a method for performing secured financial transactions between the customer account associated with the first server and the merchant in continuation of the linking, according to an embodiment of the present invention;
[0020] Figure 4 illustrates an exemplary use case of the system, according to an embodiment of the present invention;
[0021] Figure 5a illustrates a flow chart of a method for performing secured financial transactions between the customer account associated with the first server and the merchant, according to an embodiment of the present invention; and
[0022] Figure 5b illustrates another flow chart of a method for performing secured financial transactions between the customer account associated with the first server and the merchant, according to an embodiment of the present invention.
[0023] Further, skilled artisans will appreciate that elements in the drawings are illustrated for simplicity and may not have necessarily been drawn to scale. For example, the flow charts illustrate the method in terms of the most prominent steps involved to help to improve understanding of aspects of the present invention. Furthermore, in terms of the construction of the device, one or more components of the device may have been represented in the drawings by conventional symbols, and the drawings may show only those specific details that are pertinent to understanding the embodiments of the present invention so as not to obscure the drawings with details that will be readily apparent to those of ordinary skill in the art having the benefit of the description herein.

DETAILED DESCRIPTION

[0024] For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the various embodiments and specific language will be used to describe the same. 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 illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.
[0025] It will be understood by those skilled in the art that the foregoing general description and the following detailed description are explanatory of the invention and are not intended to be restrictive thereof.
[0026] Reference throughout this specification to “an aspect,” “another aspect” or similar language means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present invention. Thus, appearances of the phrase “in an embodiment”, “in another embodiment” and similar language throughout this specification may, but do not necessarily, all refer to the same embodiment.
[0027] The terms “comprises”, “comprising”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a process or method that comprises a list of steps does not include only those steps but may include other steps not expressly listed or inherent to such process or method. Similarly, one or more devices or sub-systems or elements or structures or components proceeded by “comprises... a” does not, without more constraints, preclude the existence of other devices or other sub-systems or other elements or other structures or other components or additional devices or additional sub-systems or additional elements or additional structures or additional components.
[0028] The present disclosure aims to provide secured interoperability between multiple servers owned by various financial institutes to perform a secure financial transaction between customer account and merchant.
[0029] Figure 2a illustrates a schematic block diagram depicting an environment for the implementation of a system 200 for performing a secured financial transaction between a customer account 202a associated with a first server 202 and a merchant 206, according to an embodiment of the present invention. For the sake of brevity, the system 200 to perform the secured financial transactions between the customer account 202a and the merchant 206 is hereinafter interchangeably referred to as the system 200. Figure 2b illustrates another schematic detailed block diagram of modules/software components of the system 200, according to an embodiment of the present invention.
[0030] In an embodiment, referring to Figure 2a, the system 200 may be implemented between the first server 202, a second server 208, the merchant 206, while a user 201 may be interacting with the merchant 206, the first server 202, and the second server 208. For instance, the user 201 may be using an application installed on a user device (not shown) to access the first server 202, the second server 208. Further, although only two servers, i.e., the first server 202 and the second server 208 are depicted in Figure 2a, an ordinary person skilled in the art may appreciate that more than two such servers may be present in the system 200 within the scope of this invention.
[0031] In an embodiment, referring to Figure 2a, the system 200 may include the first server 202 and the customer account 202a associated with the first server 202. In one example, the first server 202 may be operated or owned by a financial institute such as a bank. Thus, the first server 202 may be used by the bank to carry out its day-to-day financial operations, maintain customer details, provide customer services, and other functions as necessary for the bank without departing from the scope of the invention. Further, the user 201 may be interacting with the first server 202 via an instrument. In the example, the user 201 may be an owner of the customer account 202a associated with the first server 202 such that the user 201 holds access for interacting with the customer account 202a. The customer account 202a may be indicated as a financial account provided by the bank or other financial institution to the user 201. The customer account 202a may serve as a secure place to deposit and store payments or funds, as well as conduct various financial transactions. The customer account 202a may establish a banking relationship between the user 201 and the first server 202. The customer account 202a may be issued with a unique account number, which uniquely identifies the customer account 202a among many other accounts saved in a memory of the first server 202.
[0032] Further, in the example, the interaction between the user 201 and the customer account 202a may include depositing payments or funds in the customer account 202a. Alternatively, the interaction may include withdrawing payments or funds from the customer account 202a. In the example, the instruments for the user 201 to interact with the customer account 202a may be, but not limited to, an ATM card, the application installed on the user device, Web-access, virtual wallets, and alike. In the example, the user 201 may withdraw payments or funds from the customer account 202a via the instruments based on a current financial transaction limit. The current financial transaction limit may be indicative of a bank balance or the remaining funds available in the customer account 202a for performing a successful financial transaction.
[0033] In one example, the user 201 may be having the application installed on the user device (not shown) for interacting with the customer account 202a associated with the first server 202. The application may be running on an operating system (OS) of the user device that generally defines a first active user environment. The application may be indicative of a software package that performs a specific function for an end user. The OS typically presents or displays the application through a graphical user interface (“GUI”) of the OS. Other applications may be running on the operating system of the user device but may not be actively displayed. In an example, the user device may be but is not limited to, a tablet PC, a Personal Digital Assistant (PDA), a smartphone, a palmtop computer, a laptop computer, a desktop computer, a server, a cloud server, a remote server, a communications device, a wireless telephone, or any other machine controllable through the wireless-network and capable of executing a set of instructions (sequential or otherwise) that specify actions to be taken by that machine. The application may be adapted to receive input(s) from the user 201 for performing the financial transactions from the customer account 202a associated with the first server 202 to the merchant 206. Further, the application installed in the user device may also be in communication with the merchant 206 and the second server 208.
[0034] In an embodiment, the system 200 may include the second server 208 and a linked account 208a associated with the second server 208. In one example, the second server 208 may be operated or owned by a financial institute such as a bank. It may be apparent that the first server 202 and the second server 208 may be operated or owned by a single financial institute or different financial institute, within the scope of the present invention. Further, the user 201 may be the owner of the linked account 208a associated with the second server 208 such that the user 201 holds access for interacting with the linked account 208a. For the sake of brevity, the user 201 may be able to interact with the linked account 208a similar to the interaction of the user 201 with the customer account 202a.
[0035] In an embodiment, the first server 202 and the second server 208 may have interoperability such that the linked account 208a associated with the second server 208 is connected to the customer account 202a associated with the first server 202. Thus, the first server 202 and the second server 208 may be in communication with each other. In one example, the user 201 may link the linked account 208a with the customer account 202a such that both accounts may perform transactions of payments or exchange information among themselves. In the example, the first server 202 thus may be able to communicate with the second server 208 for linking the linked account 208a with the customer account 202a. In one example, the communication or the interoperability between the first server 202 and the second server 208 may be secured via the exchange of an authentication token.
[0036] In an example, the authentication token includes a single transaction unique access token which validates the communication sent by the first server 202 at the second server 208. In the example, upon linking the linked account 208a with the customer account 202a, the first server 202 may be configured to receive the authentication token generated by the second server 208. The second server 208 may be configured to generate the authentication token uniquely and send it to a corresponding server such that any future communication from the respective server may be authenticated via receiving of the authentication token. In the example, the first server 202 may be configured to store the authentication token in memory by associating the authentication token with the second server 208 and the linked account 208a based on the linking information. Further, the first server 202 may receive a revised authentication token from the second server 208 after each communication. Thus, each of the authentication tokens may be valid for a single communication. Subsequent to every communication, the second server 208 may generate the revised authentication token and share it with the first server 202. Thus, the first server 202 may store the revised authentication token in the memory by overriding the authentication token. Further, the first server 202 may communicate with the second server 208 by sending the revised authentication token to authenticate or validate the subsequent communication.
[0037] In an embodiment, the user 201 may be interacting with the merchant 206. In one example, the merchant 206 may be an online merchant or e-merchant, referring to a business or individual that conducts commercial transactions through digital or online platforms. The merchant 206 may be primarily operating in the digital realm, leveraging the internet and electronic payment systems to sell products, services, or digital goods to the user 201 without departing from the scope of the invention.
[0038] Further, the system 200 may include an entity 204. The entity 204 may be associated with the merchant 206 such that the entity 204 may facilitate the collection of payments or funds digitally from the user 201 to the merchant 206, preferably into a merchant account 206a. In one example, the merchant account 206a may be a financial account provided by the bank or other financial institution to the merchant 206. In one example, the entity 204 may indicate a service that facilitates the secure transmission of payments between the customer account 202a and the merchant 206 during an online transaction. The entity 204 may act as an intermediary between the user’s 201 chosen payment method such as a credit card, debit card, or digital wallet and the merchant account 206a associated with the financial institution, thus, ensuring the seamless and secure transfer of payments. In an example, the entity 204 may be, but not limited to, a payment gateway, a Point-of-Sale (POS) request, an Internet banking request, an ATM request, a QR code scan request, and the alike.
[0039] Referring to Figure 2a, the user 201 while interacting with the merchant 206 initiates the financial transaction. For instance, the user 201 may be making an online purchase via the payment gateway as the entity 204. Thus, the user 201 may be required to pay an amount to the merchant 206 to complete the financial transaction and conclude the intended purchase. The user 201 may provide information related to the first server 202 to the entity 204. For instance, the user 201 may provide an account address corresponding to the customer account 202a such that the entity 204 associated with the merchant 206 may identify and communicate with an associated server corresponding to the customer account 202a, i.e., the first server 202.
[0040] Further, upon initiating the financial transaction, the first server 202 may be configured to receive a request from the entity 204. The request corresponds to the amount to be deducted for the financial transaction from the customer account 202a. The request for performing the financial transaction is based on the account address provided by the user 201. Accordingly, the first server 202 may be configured to determine if the requested amount is more than the current financial transaction limit associated with the customer account. The current financial transaction limit may be indicative of a bank balance or the remaining funds available in the customer account 202a for performing a successful financial transaction.
[0041] Further, the first server 202 may be configured to send, a communication and the authentication token to the linked account 208a associated with the second server 208, upon determining that the requested amount is more than the current financial transaction limit. The communication may include a request for the deduction of a balance amount from the linked account. In the example, the balance amount is determined based on a comparison of the requested amount and the current financial transaction limit associated with the customer account 202a.
[0042] Further, the first server 202 may be configured to receive the balance amount in the associated customer account 202a from the linked account 208a in response to sending the communication and upon successful validation of the authentication token.
[0043] The first server 202 may be configured to perform the financial transaction from the customer account 202a to the entity 204 associated with the merchant 206 based on the current financial transaction limit and the balance amount. The merchant account 206a may receive the payment or fund from the customer account 202a via the entity 204. Thus, performing the secured financial transaction successfully.
[0044] In an alternative embodiment, the linked account 208a may be residing in the first server 202. In an example, the linked account 208a may indicate the bank account of the user 201 is in the bank similar to the customer account 202a such that the first server 202 may be in communication with both the customer account 202a and the linked account 208a. Thus, the user 201 may link two different accounts within the same bank for interoperability of financial transactions.
[0045] Referring to Figure 2b illustrates another schematic detailed block diagram of modules/software components of the system 200, according to an embodiment of the present invention.
[0046] In an embodiment, referring to Figures 2a and 2b, the first server 202 may include, but is not limited to, a processor 210, memory 212, modules 216, and data 214. The modules 216 and the memory 212 may be coupled to the processor 202.
[0047] The processor 210 can be a single processing unit or several units, all of which could include multiple computing units. The processor 210 may be implemented as one or more microprocessors, microcomputers, microcontrollers, digital signal processors, central processing units, state machines, logic circuitries, and/or any devices that manipulate signals based on operational instructions. Among other capabilities, the processor 210 is adapted to fetch and execute computer-readable instructions and data stored in the memory 212. At this time, one or a plurality of processors may be a general purpose processor, such as a central processing unit (CPU), an application processor (AP), or the like, a graphics-only processing unit such as a graphics processing unit (GPU), a visual processing unit (VPU), and/or an AI-dedicated processor such as a neural processing unit (NPU). One or a plurality of processors control the processing of the input data in accordance with a predefined operating rule or artificial intelligence (AI) model stored in the non-volatile memory and the volatile memory. The predefined operating rule or artificial intelligence model is provided through training or learning.
[0048] The memory 212 may include any non-transitory computer-readable medium known in the art including, for example, volatile memory, such as static random-access memory (SRAM) and dynamic random-access memory (DRAM), and/or non-volatile memory, such as read-only memory (ROM), erasable programmable ROM, flash memories, hard disks, optical disks, and magnetic tapes.
[0049] The modules 216, amongst other things, include routines, programs, objects, components, data structures, etc., which perform particular tasks or implement data types. The modules 216 may also be implemented as, signal processor(s), state machine(s), logic circuitries, and/or any other device or component that manipulates signals based on operational instructions.
[0050] Further, the modules 216 can be implemented in hardware, instructions executed by a processing unit, or by a combination thereof. The processing unit can comprise a computer, a processor, a state machine, a logic array, or any other suitable devices capable of processing instructions. The processing unit can be a general-purpose processor which executes instructions to cause the general-purpose processor to perform the required tasks or, the processing unit can be dedicated to performing the required functions. In another embodiment of the present disclosure, the processor 210 via the modules 216 is configured to execute machine-readable instructions (software) which perform the working of the first server 202 within the scope of the present invention as described in forthcoming paragraphs.
[0051] A detailed explanation of the first server 202 and the system 200 as shown in figures 2a and 2b will be explained in detail in the forthcoming paragraphs. Further, the working of the system 200 will be explained with respect to figures 2a and 2b. The reference numerals are kept the same in the disclosure wherever applicable for ease of explanation. It may be apparent for an ordinary person skill in art that, the second server 208 as shown in figures 2a and 2b may include components similar to the first server 202, within the scope of the present invention.
[0052] Figure 3a illustrates a process flow of a method 300a for linking the linked account 208a with the customer account, according to an embodiment of the present invention.
[0053] At step 302, the method 300a may include receiving, by the first server 202, the linking information indicative of an address for the second server 208 and the associated linked account 208a. Thus, based on the linking information the first server 202 may be configured to communicate with the second server 208.
[0054] At step 304, the method 300a may include linking the linked account 208a with the customer account 202a associated with the first server 202.
[0055] At step 306, the method 300a may include receiving, by the first server 202, the authentication token generated from the second server 208. The method 300 may include, storing, by the first server 202, the authentication token in the memory 212 by associating the authentication token with the second server 208 and the linked account 208a based on the linking information.
[0056] Thus, the linked account 208a associated with the second server 208 is linked with the customer account 202a associated with the first server 202 such that secured interoperability of financial transaction may be performed. The linking may be performed as a one time activity unless the user 201 manually dissociate the linked account 208a from the customer account 202a.
[0057] Figure 3b illustrates a process flow of a method 300b for performing secured financial transactions between the customer account 202a associated with the first server 202 and the merchant 206 in continuation of the linking, according to an embodiment of the present invention.
[0058] In an embodiment, in continuation with step 306, at step 308, the method 300b may include the merchant 206 initiating the financial transaction by invoking the entity 204, as the user 201 may proceed to perform the financial transaction at the merchant 206.
[0059] In an example, the financial transaction may by invoked upon the first server 202 authorizing the financial transaction i.e., by entering credentials. The credentials may be associated with the customer account 202a, to conduct the financial transaction. In the example, the credentials may indicate an identification number entered on the user device in communication with the first server 202 to successfully perform the financial transaction.
[0060] At step 310, the method 300b may include receiving, by the first server 202, the request received from the entity 204 associated with the merchant 206. In one example, the request may indicate the amount to be deducted for the financial transaction from the customer account 202a associated with the first server 202.
[0061] The method 300b may include the first server 202 determining if the requested amount is more than the current financial transaction limit associated with the customer account 202a. In one example, the first server 202 may obtain the current financial transaction limit corresponding to the customer account 202a. The current financial transaction limit may be pre-stored in the memory 212 of the first server 202. The first server 202 may compare the amount requested by the entity 204 with the current financial transaction limit and determine, whether the requested amount is within the current financial transaction limit based on comparison such that the requested amount is less than the current financial transaction limit.
[0062] At step 312, the method 300b may include sending, by the first server 202, the communication and the authentication token to the second server 208, upon determining that the requested amount is more than the current financial transaction limit.
[0063] Further the method 300b may include, the second server 208 validating the authentication token received from the first server 202 along with the communication. The communication may include the request for deduction of the balance amount from the linked account 208a. In one example, the balance amount is determined based on the comparison of the requested amount and the current financial transaction limit associated with the customer account.
[0064] At step 314, the method 300b may include receiving, the balance amount in the customer account 202a associated with the first server 202 from the linked account 208a in response to sending the communication and upon successful validation of the authentication token by the second server 208.
[0065] At step 316, the method 300b may include performing, by the first server 202, the financial transaction from the customer account 202a to the entity 204 associated with the merchant 206 based on the current financial transaction limit and the balance amount received from the linked account 208a.
[0066] At step 318, the method 300b may include the merchant 206, preferably the merchant account 206a receiving the requested amount from the customer account 202a via the entity 204. Thus, successfully performing the secured financial transaction.
[0067] In an example, the application installed on the user device may receive a notification. The application may be associated with the customer account 202a, and in communication with the first server 202. The notification may include the balance amount received by the customer account 202a, an amount deducted from the customer account 202a, and a remaining balance of the customer account 202a. Further, in real-time, a balance related to the customer account 202a and the linked account 208a may be displayed on the user device via the application.
[0068] In continuation with step 314, at step 320, the method 300b may include the first server 202 receiving a revised authentication token from the second server 208. In one example, as the authentication token may act as a one-time authentication factor and expire upon a single usage. The first server 202 may require the revised authentication to validate subsequent communication with the second server 208. Thus, the second server 208 may generate the revised authentication token after each usage or each instance of receiving the authentication token from the first server 202. In one example, the revised authentication token overrides the authentication token such that the second server 208 may validate subsequent communication only upon receiving the revised authentication token. Thus, the communication between the first server 202 and the second server 208 leads to the secured financial transaction with an exchange of the revised authentication token for each subsequent communication.
[0069] In an alternative embodiment, at step 322, the method 300b may include reversal transferring of the balance amount from the customer account 202a to the linked account 208a upon failure of the financial transaction between the customer account 202a and the entity 204. The reversal transferring may be considered as the subsequent communication and thus the balance amount may be transferred back to the linked account 208a along with the revised authentication token. In one example, the authentication token represented as ‘T1’ may be used by the first server 202 while sending the communication for the remaining amount. The second server 208 along with the balance amount sent the revised authentication token ‘T2’ for subsequent communication. Thus, while reverse transferring the balance amount from the customer account 202a to the linked account 208a, ‘T2' authentication token is used.
[0070] Figure 4 illustrates an exemplary use case of the system 200, according to an embodiment of the present invention.
[0071] In an example, the user 201 may like to perform the secured financial transaction to the merchant 206 for a purchase. The user 201 may swipe a card 402a at the POS system, wherein the card 402a may be issued by the financial institute 402. Now, the financial institute 402 via the first server 202 may determine if the requested amount is more than the current financial transaction limit available with the customer account linked to the card 402a.
[0072] In the example, the financial institute 402 via the first server 202 sends the communication and the authentication token to the linked account associated with the financial institute 404 upon determining that the requested amount is more than the current financial transaction limit. The financial institute 404 via the second server 208 receives the communication and the authentication token.
[0073] In the example, the communication may include the request for deduction of the balance amount from the linked account, Thus, the financial institute 402 via the first server 202 receives the balance amount in the associated customer account from the linked account upon successful validation of the authentication token.
[0074] Thus, as the user 201 swipes the card 402a at the POS system the financial institute 402 via the first server 202 performs the financial transaction from the customer account to the merchant.
[0075] Figure 5a illustrates a flow chart of a method 500 for performing secured financial transactions between the customer account 202a associated with the first server 202 and the merchant 206, according to an embodiment of the present invention. The method 500 may be a computer-implemented method executed, for example, by the first server 202 and the modules 216. For the sake of brevity, constructional and operational features of the system 200 that are already explained in the description of Figure 2a, Figure 2b, Figure 3a, Figure 3b, and Figure 4, are not explained in detail in the description of Figure 5a-5b.
[0076] At block 502, the method 500 may include receiving, by the first server 202, the request received from the entity 204 associated with the merchant 206. The request may indicate the amount to be deducted for the financial transaction from the customer account 202a associated with the first server 202.
[0077] At block 504, the method 500 may include determining, by the first server 202, if the requested amount is more than the current financial transaction limit associated with the customer account 202a.
[0078] At block 506, the method 500 may include sending, by the first server 202, at least one communication and the authentication token to the linked account 208a associated with the second server 208 different from the first server 202, upon determining that the requested amount is more than the current financial transaction limit. The at least one communication comprising the request for deduction of the balance amount from the linked account 208a, wherein the balance amount is determined based on the comparison of the requested amount and the current financial transaction limit associated with the customer account 202a.
[0079] Figure 5b illustrates another flow chart of a method for performing secured financial transactions between the customer account associated with the first server and the merchant, according to an embodiment of the present invention.
[0080] In continuation with the block 506, at block 508, the method 500 may include receiving, by the first server 202, the balance amount in the associated customer account 202a from the linked account in response to sending the at least one communication and upon successful validation of the authentication token.
[0081] At block 510, the method 500 may include performing, by the first server 202, the financial transaction from the customer account 202a to the entity 204 associated with the merchant 206 based on the current financial transaction limit and the balance amount.
[0082] 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 in the art, various working modifications may be made to the method in order to implement the inventive concept as taught herein.
[0083] The drawings and the forgoing 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, orders of processes described herein may be changed and are not limited to the manner described herein. , Claims:WE CLAIM:
1. A method (500) for performing secured financial transaction between a customer account (202a) and a merchant, the method (500) comprising:
receiving (502), by a first server (202), a request received from an entity (203) associated with the merchant (206), wherein the request indicates an amount to be deducted for the financial transaction from the customer account (202a) associated with the first server (202);
determining (504), by the first server (202), if the requested amount is more than a current financial transaction limit associated with the customer account (202a);
sending (506), by the first server (202), at least one communication and an authentication token to a linked account (208a) associated with a second server (208) different from the first server (202), upon determining that the requested amount is more than the current financial transaction limit, the at least one communication comprising a request for deduction of a balance amount from the linked account (208a), wherein the balance amount is determined based on a comparison of the requested amount and the current financial transaction limit associated with the customer account (202a);
receiving (508), by the first server (202), the balance amount in the associated customer account (202a) from the linked account (208a) in response to sending the at least one communication and upon successful validation of the authentication token; and
performing (510), by the first server (202), the financial transaction from the customer account (202a) to the entity (204) associated with the merchant (206) based on the current financial transaction limit and the balance amount.

2. The method (500) as claimed in claim 1, wherein to determine if the received request is within the current financial transaction limit, the method (500) further comprises:
obtaining, by the first server (202), the current financial transaction limit corresponding to the customer account, pre-stored in a memory of the first server;
comparing, by the first server (202), the requested amount with the current financial transaction limit; and
determining, by the first server, whether the requested amount is within the current financial transaction limit based on comparison such that the requested amount is less than the current financial transaction limit.

3. The method (500) as claimed in claim 2, further comprising:
performing, by the first server (202), the financial transaction from the customer account to the entity associated with the merchant based on the requested amount, the current financial transaction limit associated with the customer account such that the amount is transferred from the customer account.

4. The method (500) as claimed in claim 1, wherein the authentication token includes a single transaction unique access token which validates the communication sent by the first server (202) at the second server (208).

5. The method (500) as claimed in claim 1, prior to receiving the request, the method (500) comprises:
receiving, by the first server (202), a linking information indicative of an address for the second server and the linked account associated with the second server;
receiving, by the first server (202), the authentication token generated from the second server; and
storing, by the first server (202), the authentication token in a memory by associating the authentication token with the second server (208) and the linked account (208a) based on the linking information.

6. The method (500) as claimed in claim 1, the method (500) further comprising:
receiving, by the first server (202), a revised authentication token from the second server (208) after each communication, wherein the revised authentication token is generated by the second server (208), such that the communication sent with revised authentication token is validated;
overriding the authentication token with the revised authentication token; and
storing, by the first server (202), the revised authentication token in the memory such that the revised authentication token is sent while sending at least one subsequent communication from the first server (202) to the second server (208).

7. The method (500) as claimed in claim 1, wherein receiving the request comprises receiving, by the first server (202), the request from the entity (204) associated with the merchant (206) via at least one of: an internet banking request, a Point-of-Sale request, an ATM request, and a QR code scan request.

8. The method (500) as claimed in claim 1, further comprising:
displaying, in real time on a user device, a balance related to the customer account and the linked account associated with the authentication token stored in the first server.

9. The method (500) as claimed in claim 1, wherein performing, by the first server (202), the financial transaction comprises:
authorizing the amount transfer by entering a credentials associated with the first server, to conduct the financial transaction, wherein the credentials indicates an identification number entered on the user device in communication with the first server.

10. The method (500) as claimed in claim 1, further comprising:
sending a notification to an application on the user device, associated with the customer account, wherein the notification includes the balance amount received by the customer account, an amount deducted from the customer account, a remaining balance of the customer account, and the amount transferred.

11. The method (500) as claimed in any of the preceding claims, wherein the first server corresponds to a first bank.

12. The method (500) as claimed in any of the preceding claims, wherein the second server corresponds to a second bank different from the first bank.

13. The method (500) as claimed in any of the preceding claims, further comprising:
determining failure of the financial transaction from the customer account to the entity;
performing a revere transfer of the balance amount from the customer account to the linked account along with the revised authentication token.

14. A system (200) for performing secured financial transaction between a customer account (202a) and a merchant (206), the system (200) comprising:
a first server (202) comprising:
a memory (212);
at least one processor (210) is in communication with the memory (212), the at least one processor (210) is configured to;
receive a request received from an entity (204) associated with the merchant (206), wherein the request indicates an amount to be deducted for the financial transaction from the customer account (202a) associated with the first server (202);
determine if the requested amount is more than a current financial transaction limit associated with the customer account (202a);
send at least one communication and an authentication token to a linked account (208a) associated with a second server (208) different from the first server (202), upon determining that the requested amount is more than the current financial transaction limit, the at least one communication comprising a request for deduction of a balance amount from the linked account (208a), wherein the balance amount is determined based on a comparison of the requested amount and the current financial transaction limit associated with the customer account (202a);
receive the balance amount in the associated customer account from the linked account in response to sending the at least one communication and upon successful validation of the authentication token; and
perform the financial transaction from the customer account (202a) to the entity (204) associated with the merchant (206) based on the current financial transaction limit and the balance amount.

15. The system (200) as claimed in claim 14, wherein to determine if the received request is within the current financial transaction limit, the at least one processor (210) is configured to:
obtain the current financial transaction limit corresponding to the customer account (202a), pre-stored in a memory of the first server (202);
compare the requested amount with the current financial transaction limit; and
determine whether the requested amount is within the current financial transaction limit based on comparison such that the requested amount is less than the current financial transaction limit.

16. The system (200) as claimed in claim 15, the at least one processor (210) is further configured to:
perform the financial transaction from the customer account (202a) to the entity (204) associated with the merchant (206) based on the requested amount, the current financial transaction limit associated with the customer account such that the amount is transferred from the customer account (202a).

17. The system (200) as claimed in claim 14, wherein the authentication token includes a single transaction unique access token which validates the communication sent by the first server at the second server.

18. The system (200) as claimed in claim 14, prior to receiving the request, the at least one processor (210) is configured to:
receive a linking information indicative of an address for the second server (208) and the linked account associated with the second server (208);
receiving, by the first server (202), the authentication token generated from the second server (208); and
storing, by the first server (202), the authentication token in the memory (212) by associating the authentication token with the second server (202) and the linked account based on the linking information.

19. The system (200) as claimed in claim 14, the at least one processor (210) is further configured to:
receive a revised authentication token from the second server (208) after each communication, wherein the revised authentication token is generated by the second server (208), such that the communication sent with revised authentication token is validated;
override the authentication token with the revised authentication token; and
store the revised authentication token in the memory (212) such that the revised authentication token is sent while sending at least one subsequent communication from the first server (202) to the second server (208).

20. The system (200) as claimed in claim 14, wherein receiving the request comprises receiving, by the first server (202), the request from the entity (204) associated with the merchant (206) via at least one of: an internet banking request, a Point-of-Sale request, an ATM request, and a QR code scan request.

21. The system (200) as claimed in claim 14, the at least one processor (210) is further configured to:
display, in real time on a user device, a balance related to the customer account (202a) and the linked account (208a) associated with the authentication token stored in the first server (202).

22. The system (200) as claimed in claim 14, wherein to perform the financial transaction the at least one processor (210) is configured to:
authorize the amount transfer by entering a PIN associated with the first server, to conduct the financial transaction, wherein the PIN indicates an identification number entered on the user device in communication with the first server (202).

23. The system (200) as claimed in claim 14, the at least one processor (210) is further configured to:
send a notification to an application on the user device, associated with the customer account (202a), wherein the notification includes the balance amount received by the customer account (202a), an amount deducted from the customer account (202a), a remaining balance of the customer account, and the amount transferred.

24. The system (200) as claimed in any of the preceding claims, wherein the first server (202) corresponds to a first bank.

25. The system (200) as claimed in any of the preceding claims, wherein the second server (208) corresponds to a second bank different from the first bank.

26. The system (200) as claimed in any of the preceding claims, the at least one processor (210) is further configured to:
determine failure of the financial transaction from the customer account (202a) to the entity (204); and
perform a revere transfer of the balance amount from the customer account (202a) to the linked account (208a) along with the revised authentication token.