RELATED APPLICATION

Benefit is claimed to India Provisional Application No. 4427/CHE/2011, entitled "HUT Electronic Payment Processing System and Method" by VENUGOPAL, Sreevenkatesh filed on 16th December 2011, which is herein incorporated in its entirety by reference for all purposes.

FIELD OF THE INVENTION

The present invention relates to the field of financial transaction processing. More specifically, the present invention relates to a method and an apparatus for managing financial transactions for example, payment transaction.

BACKGROUND OF THE INVENTION

Banking systems and processes associated with it are known in the art. Typically, a back end system for performing financial transactions in banking may include two significant parts namely, a core banking system and a payment enabling hub.

The core banking system is enabled to perform internal banking related functions and the payment enabling hubs are configured for enabling financial or payment transactions that originate from a variety of payment initiator systems. Payment initiator systems include payment transaction outlets such as Automated Teller Machines (ATMs) and so on. The reason for having such different systems for different functions is to channelize the processes and reduce computing load on the core banking system which was performing both internal banking related functions and financial or payment transactions in certain legacy systems. Further, existing payment enabling hubs may require suitable software architecture to process the financial transactions efficiently.

SUMMARY OF THE INVENTION

In one aspect of the present invention, a method of managing a financial transaction is provided. The method includes the steps of receiving a request for performing a financial transaction from a first payment initiator system, determining the type of the financial transaction based on the received request, determining a request processing technique suitable based on the determined type of the financial transaction, and processing the request at an entity for performing the financial transaction.

In another aspect of the present invention, an apparatus for managing a financial transaction is provided. The apparatus includes a processor, a memory connected to the processor, loaded with one or programs for managing the financial transaction. The memory includes a transaction reception module configured for receiving one or more financial transaction requests from one or more payment initiator systems, and a request processing module configured for determining type of each of the one or more financial transaction requests, determining a request processing technique and a suitable entity for processing the request based on the type of each of the one or more financial transaction requests, and processing the request in accordance with the determined processing technique.

BRIEF DESCRIPTION OF ACCOMPANYING DRAWINGS

Figure 1 is a system level diagram for implementing method of managing payment transaction in accordance with various embodiments of the present invention.

Figure 2 a schematic view of a payment enabling hub in accordance with an embodiment of the present invention.

Figure 3a is an internal view of a memory a payment enabling hub in accordance with an exemplary embodiment of the present invention.

Figure 3b is an H-type request processing technique in a memory of a payment enabling hub in accordance with an exemplary embodiment of the present invention.

Figure 3c is a U-type request processing technique in a memory of a payment enabling hub in accordance with an exemplary embodiment of the present invention.

Figure 3d is T-type request processing technique in a memory of a payment enabling hub in accordance with an exemplary embodiment of the present invention.

Figure 4 is a flow chart providing a method of managing financial transaction in accordance with an exemplary embodiment of the present invention.

The above listed figures are for illustrative purposes only and shall not be construed as limitations in any sense.

BREIF DESCRIPTION OF THE INVENTION

The present invention relates to method and apparatus for managing financial transactions. In the following detailed description of the embodiments of the invention, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the invention may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the invention, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present invention. The following detailed description is, therefore, not to be taken in a limiting sense, and the scope of the present invention is defined only by the appended claims.

Figure 1 is a system 100 for implementing financial transaction management method in accordance with various embodiments of the present invention.

The system 100 includes one or more payment initiator systems 102(a-n) connected to a payment enabling hub 104. The payment enabling hub 104 is connected to a banking server 106. In the present embodiment, the payment enabling hub 104 is shown as one in count for illustration. However, there can be number of payment enabling hubs such as 104 connected with the payment initiator system 102a and the banking server 106. Each of the payment enabling hubs 104 can be dedicated for a set of functions. The payment initiator system 102a can be connected with the payment enabling hub 104 through both wired and wireless networking means. Similarly, the payment enabling hub 104 and the banking server 106 can be connected through wired and wireless networking means.

In accordance with an exemplary embodiment, the payment enabling hub 104 and the banking server 106 are a part of internal hardware system of a financial institution and are generally present in a close proximity. Further, the payment enabling hubs 104 are configured for facilitating financial transactions of an account holder in the financial institution. The banking server 106 shall be configured for

maintaining books or accounts and other banking related information such as treasury related information, cash inflow, cash outflow and so on.

For example, whenever the account holder performs a financial transaction through the payment initiator system 102a, the payment enabling hub 104 facilitates the financial transaction and the transaction related information is transferred in the form of messages to the banking server 106. The banking server 106 updates information in an associated database (not shown in the figure).

Figure 2 a schematic view of the payment enabling hub 104 in accordance with an embodiment of the present invention.

The payment enabling hub 104 includes a memory 202, a processor 204, a bus 206, a communication interface 208, a transmitter 210, a receiver 212, and an auxiliary memory 220. The memory 202 includes a transaction reception module 214, an adaptor module 216, and a request processing module 218.

In accordance with the present embodiment, the transaction reception module 214 is configured for receiving one or more financial transaction requests from one or more payment initiator systems such as 102a. For example, the transaction reception module 214 can be a top layer of the memory 202 to receive requests as a message with all required fields and data for performing the financial transaction. Further, the transaction reception module 214 is configured to receive message from any financial transaction outlet in any format.

For example, the adaptor module 216 can be a middle layer of the memory 202. The adaptor module 216 is configured for converting the received message of different formats to the required format in the payment enabling hub 104. The adaptor module 216 is configured to read messages and details associated with it, as received at the transaction reception module 214. Thereafter, the adaptor module 216 performs a transcoding operation or performing a format translation on each of the received messages and converts them to machine readable format of the hub 104.

In an exemplary embodiment, the adaptor module 216 facilitates transfer of processed messages and requests to different entities within the memory 202 of the payment enablement hub 104, as instructed by the request processing module 218. For instance, in such cases of facilitating transfer of messages, the adaptor module 216 provides a transfer path with respect to one or more request processing techniques adopted by the request processing module 218. One or more request processing techniques include H-type processing technique, U-type processing technique, and T-type processing technique.

The request processing module 218 is configured for processing the requests for performing financial transactions. In one particular embodiment, the request processing module 218 receives formatted request from the adaptor module 216.

The request processing module 218, particularly configured for performing one or more steps including determining type of each of the one or more financial transaction requests, determining a request processing technique and a processing entity based on the type of each of the one or more financial transaction requests, and directing the one or more financial transaction requests for processing the financial transaction. While determining the type of the financial transaction request, the request processing module 218 identifies the type of the request to be one of an individual payment request, a bulk payment request, and a request requiring response within a threshold time. On determining the type of the request, the request processing module 218 is configured for determining the type of request processing technique. If required, the request processing module 218 performs the computational steps to process the financial transaction request within the payment enabling hub 104. Alternatively, the request processing module 218 is configured to direct the request to a suitable entity, wherein the entity can be an internal entity, that is, within the payment enabling hub 104 or an external entity. For example, the suitable entity can also be the request processing module 218 or any module configured to manage the financial transaction. In one or more embodiments, the above mentioned steps can be installed as business logic for a financial institution and can be configured or loaded as one or more programs particular to that financial institution.

In one or more embodiments, the processed requests of financial transactions and associated outputs are stored in the auxiliary memory 220. In accordance with various embodiments, the auxiliary memory 220 acts as a storage unit which can be one of a file storage system, a database management system, a relational data base management system etc. which can permanently store data or processed data that can be retrieved at any point in time on need basis.

The memory 202 may be volatile memory and non-volatile memory. In one embodiment, the memory 202 including the transaction reception module 214, the adaptor module 216, and the request processing module 218 are configured as computer readable programs. According to the embodiments of the present subject matter, a variety of computer-readable storage media may be stored in and accessed from the memory elements. Memory elements may include any suitable memory device(s) 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, hard drive, removable media drive for handling memory cards, Memory SticksTM, and the like. Embodiments of the present subject matter may be implemented in conjunction with modules, including functions, procedures, data structures, and application programs, for performing tasks, or defining abstract data types or low-level hardware contexts. For example, the memory 202 with programs can also be stored in the form of machine-readable instructions on any of the above-mentioned storage media and is executed by the processor 204. In one embodiment, the computer program may be included on a storage medium and loaded from the storage medium to a hard drive in the non-volatile memory.

For example, the processor 204 as used herein, means any type of computational circuit, such as, but not limited to, a microprocessor, a microcontroller, a complex instruction set computing microprocessor, a reduced instruction set computing microprocessor, a very long instruction word microprocessor, an explicitly parallel instruction computing microprocessor, a graphics processor, a digital signal processor, or any other type of processing circuit. The processor 204 may also include embedded controllers, such as generic or programmable logic devices or arrays, application specific integrated circuits, single-chip computers, smart cards, and the like.

Figure 3a is an internal view of the memory 202 of the payment enabling hub 104 in accordance with an exemplary embodiment of the present invention.

In accordance with the present embodiment, the memory 202 is shown in the form of successive layers. As shown in the figure 3a, the first layer in the memory 202 is the transaction reception module 214, the second layer is the adaptor module 216, and the third layer is the request processing module 218. There are three processing techniques that can be employed by the transaction request processing module 218 such as the H-type processing technique, the U-type processing technique, and the T-type processing technique. For illustrative purposes only, the presented processing techniques are called as 'HUT' model for processing the requests. A scheme of the H-type processing technique is shown as 302, the U-type processing technique 304 and the T-type processing technique 306. The request processing module 218 determines one of the processing techniques to be suitable for the transaction request.

Figure 3b is the H-type request processing technique 302 in the memory 202 of the payment enabling hub 104 in accordance with an exemplary embodiment of the present invention.

The H-type request processing technique 302 is shown illustratively in the figure 3b. The transaction reception module 214 receives one or more requests with varieties of formats, for example, in the form of message. The adaptor module 216 performs the transcoding step or performing a format translation and thereby converts the request in the machine readable format for the payment enabling hub 104. The converted request is processed in the request processing module 218 at an application level and thereafter, stored in the auxiliary memory 220. The output of the request is transmitted to a suitable external entity. In accordance with the H-type processing techniques, requests related to payment transactions that require extra care are processed individually leveraging on the resources and lesser stringent response requirements or computational processes.

Figure 3c is the U-type request processing technique 304 in the memory 202 of the payment enabling hub 104 in accordance with an exemplary embodiment of the present invention.

The U-type request processing technique 302 is shown illustratively in the figure 3c. The transaction reception module 214 receives one or more requests with varieties of formats. The adaptor module 216 performs the transcoding step or performs a format translation and converts the request in the machine readable format for the payment enabling hub 104. The converted request is, thereafter, stored in the auxiliary memory 220 and then processed by the request processing module 218. For example, if the auxiliary memory 220 is a relational database, upon inserting the request related data into the memory 220, a trigger invokes a stored procedure to process the payment transaction. The output is, thereafter, transmitted to the external entity such as the banking server 106. In accordance with the U-type request processing technique 304, payments or financial transactions that are to be processed in bulk or high in number are processed, where the input and output are group of transactions.

Figure 3d is the T-type request processing technique 306 in the memory 202 of the payment enabling hub 104 in accordance with an exemplary embodiment of the present invention.

The T-type request processing technique 302 is shown illustratively in the figure 3d. In accordance with the present embodiment, the request for financial transaction is not processed in the payment enabling hub 104. The transaction reception module 214 receives the request for financial transaction and thereafter, the adaptor module 216 converts the request to a machine readable format. The converted or transcoded or translated request is stored in the auxiliary memory 220. The output, without processing is transmitted to the external entity.

Figure 4 is a flow chart providing a method 400 of managing financial transaction in accordance with an exemplary embodiment of the present invention.

The method 400 includes a plurality of steps from 402 to 414. In step 402, the payment enabling hub 402 receives the request for performing a financial transaction from one or more payment initiator system such as 102a. In step 404, the request in the form of message is performing a format translation or converted to suitable format. Thereafter, the type of request is determined in step 406. The determined type of request may be one of an individual payment request, a bulk payment request, and a request requiring computational processing greater than a threshold. The request processing module 218 determines the processing entity and a suitable processing technique (H-type, U-type, and T-type) based on the type of the request received in step 408.

In step 410, the request processing module 218 directs the request to the suitable entity to process the request or can determine to process the request by itself, which is based on the determined processing technique as explained in step 408. In step 412, the request is processed at the request processing module 218, if the determined processing technique is one of H-type 302 and U-type processing technique 304. Thereafter, in step 414, a command of performing transaction is provided by the payment enabling hub 214. The command can be transferred to the banking server 106 for updates in individual account holders' books.

The present embodiments have been described with reference to specific example embodiments; it will be evident that various modifications and changes may be made to these embodiments without departing from the broader spirit and scope of the various embodiments. Furthermore, the various devices, modules, selectors, estimators, and the like described herein may be enabled and operated using hardware circuitry, for example, complementary metal oxide semiconductor based logic circuitry, firmware, software and/or any combination of hardware, firmware, and/or software embodied in a machine readable medium.

We claim:

1. A method of managing a financial transaction, comprising:

receiving a request for performing a financial transaction from a first payment initiator system;

determining the type of the financial transaction based on the received request;

determining a request processing technique suitable based on the determined type of the financial transaction; and

processing the request at an entity for performing the financial transaction.

2. The method according to claim 1, wherein in processing the request at the entity for performing the financial transaction, the step comprises:

ascertaining the one of the processing entities is an external entity.

3. The method according to claim 1, wherein in processing the request at the entity for performing the financial transaction, the step comprises:

ascertaining the one of the processing entities is an internal entity.

4. The method according to claim 1, wherein the type of the financial transaction requested comprises an individual payment request, a bulk payment request, and a request requiring response within a threshold time.

5. The method according to claim 1, further comprising:

performing a format translation the request to a suitable form to facilitate determination of the type of the financial transaction, the request including a message with a list of parameters related to the financial transaction.

6. An apparatus for managing a financial transaction, comprising:

a processor;

a memory connected to the processor, loaded with one or programs for managing the financial transaction, the memory comprising:

a transaction reception module configured for receiving one or more financial transaction requests from one or more payment initiator systems; and

a request processing module configured for:

determining type of each of the one or more financial transaction requests;

determining a request processing technique and a suitable entity for processing the request based on the type of each of the one or more financial transaction requests; and

processing the request in accordance with the determined processing technique.

7. The apparatus as recited in claim 6, wherein the memory further comprises an adaptor module configured for performing a format translation for the one or more financial transaction requests to a device readable format.

8. The apparatus as recited in claim 6, wherein the request processing module further configured for identifying the request to be one of an individual payment request, a bulk payment request, and a request a request requiring response within a threshold time.

9. The apparatus as recited in claim 6, wherein the request processing module is further configured for ascertaining the one of the processing entities is an external entity.

10. The apparatus as recited in claim 6, wherein the request processing module is further configured for ascertaining the one of the processing entities is an internal entity.