Abstract:
A fund transfer information presentation system and method capable of suitably tracking deposit asset trends for a client in order to maintain and strengthen reliable and efficient financing capability which is the source of maximum profit for a bank required for securing management gains for not only the conventional asset-side but also for the liability-side. Transaction histories within a period specified by parameters are subject to name identification by client and chronologically ordered. Thereafter, they are separated into deposits and withdrawals, wherein the deposit and withdrawal transactions are split into ranges wherein individual transaction amounts match and matching transactions are associated one-to-one, and the one-to-one correspondences of the deposit and withdrawal transactions are arranged in order of time of occurrence to generate Fund transfer details between products by client.

Description:
TECHNICAL FIELD 
       [0001]    The present invention relates to a fund transfer information presentation system which utilizes a computer to produce a “visualization” of preferences and needs of financial transactions and deposit asset trends for a client, which enables the characterization of naturally characterless funds in the scope of upgrading client management and Asset Liability Management (especially liability management) of financial institutions. Said visualization is achieved by importing to the computer transaction information from a core banking system or the like and conducting name identification by client for the imported transaction information. 
       BACKGROUND ART 
       [0002]    A deposit spread is defined as an interest differential between a market interest rate (the rate to be applied for borrowing or lending among financial institutions) and a deposit interest rate. The deposit spread started to shrink in about 1990, and reached almost zero by the end of the nineties, at a time when the market interest rate approached zero. In contrast, a loan spread is defined as an interest differential between a loan interest rate and a market interest rate (the rate to be applied for borrowing or lending among financial institutions), which had been fluctuating in negative values, and started to increase in 1991 causing the source of profit (loan-deposit spreads) to shift from the deposit spread to the loan spread. Consequently, Asset Liability Management (hereinafter referred to as ALM) programs of financial institutions which are used to control the total management of assets and liabilities started to focus on profit increase arising out of assets, over those of liabilities. 
         [0003]    Accordingly, for example in Patent Document 1, there is disclosed a system which enables one to make inquiries of transaction information for use in analyzing the portfolio at a given point in time or given short/long period of time, for the purpose of maximizing the returns (profit) arising out of the total assets of financial institutions, contrary to the conventional way of making inquiries operated with periodical cycles on a long-term basis, for example every fiscal term, monthly, etc. 
         [0004]    Further, in Patent Document 2, there is disclosed a method of indicating portfolio information on a graph with axes of risk rate and profit rate which enables users to understand the presentation without difficulty, contrary to the conventional method operated with numerical numbers. 
         [0005]    However, the source of maximum profit for a bank is a reliable, low-interest financing capability. In this respect, it is necessary to maintain and expand the client base by appropriately perceiving the preferences and needs of financial transactions by a client which is followed by developing and offering the client suitable products/services. Further, it is expected that the deposit spread defined as the interest differential between the market interest rate and the deposit interest rate will be normalized in the future, and that the market interest rate will rise. Because securing gains in the credit business tends to be difficult these days due to the stagnant corporate lending and housing loans facing increased competition, the result is that securing gains arising out of the deposit spread is important. In addition, management of deposit assets from the perspective of asset building for a client is also important, bringing in commission incomes from sales of investment funds or insurance products or the like, in view of diversifying asset building methods for a client. Thus, securing reliable and efficient financing capability and increasing management gains are required, which is obtained by estimating needs of prospective clients and predicting changes in the financial environment, followed by appropriate action. In this respect, not only is it required to perceive the preferences and needs of a client&#39;s financial transactions and track the increase/decrease and transfer histories of a client&#39;s deposit assets, but it is also required to grasp, analyze and monitor whole transaction elements from a variety of angles, by accumulating client information data by categories such as age, sex, an attribution like region, product, and period. 
       PRIOR ART PATENT DOCUMENTS 
     Patent Document 1: 
       [0000]    
       
         Japanese Patent Application Laid-Open No. 2003-281360 
       
     
       Patent Document 2: 
       [0000]    
       
         Japanese Patent Application Laid-Open No. 2002-297894 
       
     
       SUMMARY OF THE INVENTION 
       [0008]    To solve the problems described above, the fund transfer information presentation system of the present invention enables one to perceive the preferences and needs of financial transactions by a client while concurrently tracking the increase/decrease and transfer histories of the deposit assets by the client, which is required for the management of not only the conventional asset-side but also of the liability-side. Also it enables one to analyze the entire deposit assets from a variety of angles which is thereafter followed by monitoring, so that one is capable of suitably tracking the deposit asset trends for the client. 
         [0009]    In order to solve the problems shown above, the fund transfer information presentation system of the present invention contains features defined as follows: 
         [0010]    First, the output journal logs are imported from the core banking system to a database on a computer. Second, a computer program is used to extract the deposit and withdrawal transactions from the journal logs within a period specified by parameters. Said deposit and withdrawal transactions are subject to name identification by client, which is followed by the processing of data on the computer respectively defined as follows: 
         [0011]    When a fund transfer detail is settled by a single transaction, a computer program using an association function based on attribute-linked fund transfer is used to arrange individual transactions within a period specified by the parameter in order of time of occurrence, which results in the generation of fund transfer details by client. Such fund transfer details can be viewed on the computer, printed out, or sent electronically to another computer or phone. 
         [0012]    In addition, when a fund transfer detail is not settled by a single transaction, a computer program using an association function based on logical fund transfer is conducted by processing the data on a computer as described below: 
         [0013]    First the individual transactions within a period specified by the parameter are arranged in order of time of occurrence. Second, the transactions are separated into deposits and withdrawals, and if the total amounts of the deposits and the withdrawals are not equivalent, the differential value between the two amounts is allocated to the side with the least value of the amount as a dummy transaction in order to balance the total amount of deposits and withdrawals. Further, the deposit and withdrawal transactions are split into ranges wherein individual transaction amounts match and matching transactions are associated one-to-one, and the one-to-one correspondences of the deposit and withdrawal transactions are arranged in order of time of occurrence, which results in the generation of fund transfer details between products by client. Such fund transfer details can be viewed on the computer, printed out, or sent electronically to another computer or phone. 
         [0014]    Herein, when the processing of the association function based on the logical fund transfer, results in transactions which are defined as “dummy” due to the lack of a target transaction to be matched thereto within a period specified by the parameter, another round of association function processing is conducted on the computer using a re-match program to re-match the transaction data within an extended period specified by a renewed parameter value so that dummy transactions are to be reduced. Thereafter, when there are dummy transactions which have formed as a result of the re-matching in both the deposit and withdrawal side, they are offset by value and the remainder of the difference is allocated either to the deposit side or to the withdrawal side as newly-formed dummy data so that dummy transactions are to be further reduced. 
         [0015]    Moreover, while processing the association function based on logical fund transfer on the computer, in the case where there are ordinary deposits for settlement both in the deposit side and in the withdrawal side, a two-step association function is conducted on the computer by offsetting the ordinary deposits by value and allocating the remainder of difference either to the deposit side or to the withdrawal side as newly-formed ordinary deposit for settlement, so that ordinary deposits for settlement are reduced. 
         [0016]    As a result of the respective processing, fund transfer details between products by the client are generated wherein a product name of a withdrawal transaction is stated as a fund source for a financial product purchase, a product name of a deposit transaction is stated as beneficiary (i.e., fund destination) of financial product disposal, and a transfer amount is stated as a transaction amount, which enables one to present deposit asset trends for a client. 
         [0017]    For example, if funds are withdrawn from an ordinary deposit, the product name of the withdrawal transaction “ordinary deposit” is the fund source for the purchased financial product “investment fund”. On the other hand, when funds are deposited in an ordinary deposit account, the product name of the deposit transaction “ordinary deposit” is the beneficiary (fund destination) of the closed (sold) financial product “term deposit”. The present invention enables one to perceive and present deposit asset trends, by setting a source/destination of funds so that fund transfer details by client is generated. Fund Transfer details are shown in  FIG. 2 ,  FIG. 3 ,  FIG. 6 , and  FIG. 8 . 
         [0018]    As described above, the present invention produces the “visualization” of deposit asset trends for a client, by the data processing on a computer defined as follows: 
         [0019]    First, the output journal logs of actual client transaction data are imported from the core banking system to a transaction history database on a computer, and second, a computer program is used to extract the deposit and withdrawal transactions from the journal logs therein within a specified period. Said deposit and withdrawal transactions are subject to name identification by client, which is followed by the data processing on a computer respectively defined as follows: 
         [0020]    When a fund transfer detail is settled by a single transaction, a computer program using an association function based on an attribute-linked fund transfer is conducted. 
         [0021]    When a fund transfer detail is not settled by a single transaction, a computer program using an association function based on logical fund transfer is conducted, which is followed by another round of association function and/or the two-step association function when executable. 
         [0022]    Said variety of association functions eventually lead to generate fund transfer details via a report on a computer between products wherein a product name of a withdrawal transaction is stated as a fund source for a financial product purchase, a product name of a deposit transaction is stated as a beneficiary of a financial product disposal, and a transfer amount is stated as a transaction amount, so that the “visualization” is achieved. Such fund transfer details can be viewed on the computer, printed out, or sent electronically to another computer or phone, or other electronic device. 
         [0023]    Consequently, it is possible to perceive preferences and needs of financial transactions and deposit asset trends for a client in accurate details on a timely basis, giving operational management the ability to secure reliable and efficient financing capability. 
     
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         [0024]      FIG. 1  is a configuration diagram of the fund transfer information presentation system according to one embodiment of the present invention. 
           [0025]      FIG. 2  is a data-flow chart of the computer program association function based on attribute-linked fund transfer as it used on the transaction history to produce fund transfer details for a client in accordance with the present invention. 
           [0026]      FIG. 3  is a data-flow chart of the computer program association function based on logical fund transfer as it used on the transaction history to produce fund transfer details for a client in accordance with the present invention. 
           [0027]      FIG. 4  is a flow chart of the processing of the computer program association function based on attribute-linked fund transfer wherein transaction histories are separated into deposits and withdrawals in accordance with the present invention. 
           [0028]      FIG. 5  is a flow chart of the processing of the computer program association function based on attribute-linked fund transfer and matching for generating fund transfer details between products in accordance with the present invention. 
           [0029]      FIG. 6  is a data-flow chart of showing another round of the computer program association based function in accordance with the present invention. 
           [0030]      FIG. 7  is a flow chart of another round of the computer program association function in accordance with the present invention. 
           [0031]      FIG. 8  is a data-flow chart of the two-step computer program association function in accordance with the present invention. 
           [0032]      FIG. 9  is a flow chart of the computer program two-step association function in accordance with the present invention. 
       
    
    
     DETAILED DESCRIPTION OF THE INVENTION 
       [0033]    Hereinafter, embodiments of this invention will be explained in detail. 
         [0034]      FIG. 1  shows a configuration diagram of the fund transfer information presentation system when carried out on a computer in the present invention. First, computer Transaction history database  1  (which has been exported from the core banking system) is entered by a computer program having an association function based on attribute-linked fund transfer so that target transaction data for the client within a specified period is extracted. Thereafter the results of the said association function are output to Transfer detail computer database  2  ( 101 ). One may set a single day as a specified period, since bank transactions are completed on a daily basis. Moreover, said period can be specified by entering a parameter value by a user. While a single day may be set as a specified period, it is preferred to be set to two days, that is, a single day with the day after (the next day), so that an another round of association function which described later is to be conducted. In another embodiment, a week may be set as a specified period. Although a plurality of clients can be included in parallel when an association function is conducted, a case with a single client will be explained hereinafter. 
         [0035]    The following refers to transactions within a single bank account of a client. When the client holds more than one bank account, they can be treated as a combined one. That is, in the present system, a client can be identified not only by a single bank account but also by a plurality of bank accounts which belong to the client. 
         [0036]    Computer transaction history database  1  stores journal logs (transaction histories) of the deposit/withdrawal information of the client. This information comes from the core banking system wherein ordinary transactions such as account related proceedings of the bank are dealt with. Specifically, computer transaction history database  1  stores transaction data, wherein each of the data transactions contains a client name, an account type, a distinction of deposit/withdrawal, a transaction amount, a transaction date, a detail of the transaction, and the like. The detail of the transaction may be, for example, a direct deposit of salary, a remittance to another bank (both incoming remittance and outward remittance), a receipt of public pension payments, a public utility bill payment, and the like. Further, said computer transaction history database  1  comprises various types of indexed files so that the stored data can be connected with each other and appropriate corrections can be made, concurrently with a simple memorizing means therein which stores various data in a preset data format. 
         [0037]    Said computer program association function based on attribute-linked fund transfer represents a fund transfer whose detail is settled by a single transaction relating to some particular transaction such as a direct deposit of salary, or a remittance to another bank or the like. The present system extracts particular transactions which can be targeted for the computer program association function based on attribute-linked fund transfer from the entire transaction data. That is, a particular transaction which is apart of the preset particular transactions is to be identified by the transaction data, since it contains the specific data which settles the detail of the transaction therein. If necessary, it is possible to create a table of the detailed data for identifying the target data for the computer program association function based on attribute-linked fund transfer, so that the actual target data for the said association function based on attribute-linked fund transfer is determined by comparing the actual transaction data and the stored data within the said table. 
         [0038]    As shown in  FIG. 2 , the computer program association function based on attribute-linked fund transfer is conducted within a period specified by parameters, by arranging the target transaction histories which are subject to name identification by client in chronological order ( 201 ), leading to generate fund transfer details between products by client ( 202 ) by rearranging the individual transactions in order of time of occurrence. 
         [0039]      FIG. 1  also shows when computer transaction history database  1  is entered so that target transactions for the computer program association function based on logical fund transfer within a specified period are extracted by client and the results are output to computer work table  3  with some necessary information added thereto ( 102 ). Fund transfers targeted for the computer program association function based on attribute-linked fund transfer represent fund transfers whose detail can be settled in one transaction. Fund transfers targeted for the computer program association function based on logical fund transfer represent fund transfers whose detail cannot be settled in one transaction, and matching is needed. When a transaction is targeted for the computer program association function based on attribute-linked fund transfer, it is not targeted for the computer program association function based on logical fund transfer. In other words, when a transaction is targeted for the logical fund transfer, inevitably it means the transaction is not targeted for the association function based on attribute-based fund transfer. Herein, the computer program association function based on logical fund transfer is defined as a processing wherein details cannot be settled in one transaction and are settled by associating a plurality of transactions of the client in order of time of occurrence. Therefore, to generate fund transfer details using the computer program association function based on logical fund transfer, the process of matching is needed. 
         [0040]    As shown in  FIG. 3 , the computer program association function based on logical fund transfer processes transaction histories on a computer within a period specified by parameters that are subject to name identification by client and chronologically ordered ( 301 ), then separated into deposits and withdrawals ( 302 ) tables for further processing. A computer program splits the deposit and withdrawal transactions into ranges wherein individual transaction amounts match and matching transactions which are equivalent amount are associated one-to-one ( 303 ), and the one-to-one correspondences of the deposit and withdrawal transactions are arranged in order of time of occurrence so as to generate fund transfer details between products by client ( 304 ). 
         [0041]    Referring now to  FIG. 1 , a computer program sends the fund transfer details to the computer work table  3  where the fund transfer details are split into deposits (balance-increasing transactions) and withdrawals (balance-decreasing transactions), so that each of them is to be output either to Deposit table  4  or to Withdrawal table  5  ( 103 ). At this stage, the total amounts of the deposits and the withdrawals are compared so that the differential value between the two amounts is allocated to the side with the least value of the amount as a dummy transaction amount for a dummy data (other), in order to balance the total amount of deposits and withdrawals. In  FIG. 3 , the dummy data (“other”) is considered to be a cash transaction. As a result, the total amounts of the deposits and the withdrawals within a specified period are to be equally-balanced due to the added dummy deposit/withdrawal data (“other”). Said balancing process is conducted for the target data for the computer program association function based on logical fund transfer. 
         [0042]    As shown in the flow chart of  FIG. 4 , the above computer processing is conducted as follows: First, the transaction data is loaded from Work table  3  (S 101 ), and second it is determined whether or not it is the end of data of the client (S 102 ), and if not considered to be the end data of the client, then it is determined whether or not it is a deposit transaction (S 103 ). On the other hand, if it is considered to be the end data of the client, the deposit value is added to the total deposit amount (S 104 ). And finally, the transaction data is output to Deposit table  4  (S 105 ), which is followed by the stage S 101  to load the next transaction data thereafter. 
         [0043]    At the stage of S 103 , if it is not deemed to be a deposit transaction, the withdrawal value is added to the total withdrawal amount (S 106 ), then the transaction data is output to Withdrawal table  5  (S 107 ), which is followed by the stage  5101  to load the next transaction data thereafter. 
         [0044]    At the stage of S 102 , if deemed to be the last data of the client, the total deposit amount and the total withdrawal amount are compared (S 108 ), in order to form a dummy data (other) which is defined as follows: 
         [0045]    When the total deposit amount&gt;the total withdrawal amount, the dummy data is formed to be “the transaction amount=the total deposit amount−the total withdrawal amount” (S 109 ). Thereafter, the formed dummy data is output to Withdrawal table  5  (S 110 ), which is followed by the stage S 113 . 
         [0046]    When the total deposit amount&lt;the total withdrawal amount, the dummy data is formed to be “the transaction amount=the total withdrawal amount−the total deposit amount” (S 111 ). Thereafter, the formed dummy data is output to Deposit table  4  (S 112 ), which is followed by the stage S 113 . 
         [0047]    When the total deposit amount=the total withdrawal amount, no dummy data is formed. Instead, it is determined whether or not it is the end of Work table  3  (S 113 ), and if it is not considered to be the end, then it is followed by the stage  5101  and the next transaction data is loaded On the other hand, if it is determined to be the end, then the proceeding is completed. 
         [0048]    Herein, the formed dummy data (other) is preferred to be considered as a cash deposit or a cash withdrawal. 
         [0049]    As a result, the deposit/withdrawal transaction data of the client which are stored in Work table  3  within a specified period are output either to Deposit table  4  or to Withdrawal table  5 , in the form of equally-balanced. 
         [0050]    Referring again to  FIG. 1 , the deposit and withdrawal transactions are split into ranges wherein individual transaction amounts match and matching transactions are associated one-to-one, and the one-to-one correspondences of the deposit and withdrawal transactions are output to Fund transfer detail database  2  ( 104 ) as fund transfer details between products by client. As a result, fund transfer details between products within a specified period are generated from the transactions that were targeted for the computer program association function based on logical fund transfer out of the journal logs. 
         [0051]    The flow chart of  FIG. 5  shows a computer program process flow for generating fund transfer details between different products. According to  FIG. 5 , first a transaction data is loaded from the Withdrawal table  5  to be stored in memory on the withdrawal side (S 201 ). Second, it is determined whether or not the transaction data is the end of Withdrawal table  5  (S 202 ), and if it is considered to be the end, then the processing is complete. On the other hand, if it is not considered to be the end, another transaction data is loaded from Deposit table  4  to be stored in a memory on the deposit side (S 203 ). 
         [0052]    Next, the deposit amount and the withdrawal amount are compared (S 204 ). In the case where the deposit amount the withdrawal amount, the withdrawal amount is set as the “transfer amount” of the fund transfer detail (S 205 ). On the other hand, when the deposit amount&lt;the withdrawal amount, the deposit amount is set as the “transfer amount” of the fund transfer detail (S 206 ). 
         [0053]    Then, the product name of the withdrawal transaction is set to the “from” side of the fund transfer detail (S 207 ), and the product name of the deposit transaction is set to the “to” side of the fund transfer detail (S 208 ). Thereafter, the generated fund transfer detail is output to fund transfer detail database  2  (S 209 ). “Product names” refer to the transactions or services offered by the financial institutions. In addition to product names such as “ordinary deposit”, “term deposit”, “investment fund” and “cash”, are product names such as “insurance product”, “bonds”, “debentures”, “securities” and the like. Other product names may be used as considered appropriate. 
         [0054]    Further, the deposit amount and the withdrawal amount are compared (S 210 ), in order to change the transaction amount defined as follows: 
         [0055]    When the deposit amount&gt;the withdrawal amount, the transaction amount of the deposit-side memory is changed to be “the transaction amount=the deposit amount−the withdrawal amount” (S 211 ). Thereafter, the next data is loaded from Withdrawal table  5  to be stored in the withdrawal-side memory (S 212 ), which is followed by the stage S 204 . 
         [0056]    When the deposit amount&lt;the withdrawal amount, the transaction amount of the withdrawal-side memory is changed to be “the transaction amount=the withdrawal amount−the deposit amount” (S 213 ). Thereafter, the next data is loaded from Deposit table  4  to be stored in the deposit-side memory (S 214 ), which is followed by the stage S 204 . 
         [0057]    When the deposit amount=the withdrawal amount, no change is to be made and the computer program goes back to stage S 201 . 
         [0058]    Thus, the process of building corresponding relationships (i.e. matching) is conducted sequentially in order of time of occurrence for the output transaction data which is stored in Deposit table  4  and Withdrawal table  5 . As described above, the amounts of deposit/withdrawal are equally-balanced inevitably due to the added dummy data. Therefore, the matching of the transaction data within Deposit table  4  and Withdrawal table  5  is completed since the total deposit amount=the total withdrawal amount, which generates the completion of the fund transfer details. 
         [0059]    Referring again to  FIG. 1 , a transaction which is already stored in Fund transfer detail database  2  is also used as a target transaction for either another round of the computer program association function or the two-step computer program association function, when the transaction date applies to the specified period for the association function. In the processing of another round with the computer program association function, the fund transfer data are split into deposit transactions and withdrawal transactions and output to Work table  3  ( 105 ). Thereafter, the split transactions are transformed to deposit transaction data and withdrawal transaction data, which are inserted into either Deposit table  4  or Withdrawal table  5  respectively ( 103 ). In the processing of the two-step computer program association function, the fund transfer data are split into deposit transactions and withdrawal transactions and output to Two-step computer program association function work table  6  ( 106 ). Thereafter, the split transactions are transformed into deposit transaction data and withdrawal transaction data, which are then inserted into either Two-step computer program association function deposit table  7  or Two-step computer program association function withdrawal table  8  respectively ( 107 ). 
         [0060]    Herein, another round of the computer program association function is defined as the process wherein re-matching is conducted within the extended period specified by the present parameter, in with regard to the transaction which is defined as “other” due to the lack of a target transaction to be matched thereto, with the aim of reducing the dummy transactions. 
         [0061]    For example, explained below is a case where the parameter value is set to two days and is concurrently followed by the processing of the daily computer program association function based on logical fund transfer. In this instance, the processing by the computer program association function based on logical fund transfer of a day is to be completed at the end of the following day, by matching the transaction defined as “other” on the first day to the transaction of the second day. 
         [0062]    As described above, in the processing by another round of the computer program association function, the computer program association function based on logical fund transfer is conducted such that the two-day transaction data are output collectively either to Deposit table  4  or to Withdrawal table  5  and the dummy data “other” is formed by the differential value between the two-day deposit/withdrawal transactions. This processing enables one to re-match the transaction defined as “other” on the first day to the transaction of the second day.” 
         [0063]    Further a case of client A is explained in detail by referring to  FIG. 6 . First, the transaction history within a time period specified by the date parameter ( 401 ) is integrated with the formerly generated fund transfer details within the same specified time period ( 402 ). Hereafter each of the transactions are arranged in chronological order and separated into deposits and withdrawals ( 403 ). When there is a transaction defined as “other (¥300,000)” in the former fund transfer details ( 402 ), said transaction is matched to the present transaction history ( 401 ) “other (¥400,000)” so as to be offset by value, which allows for the reduction of the dummy transactions. Thereafter, the remainder of difference (¥100,000) is allocated to the deposit side as a positive quantity of the newly-formed dummy transaction “other (¥100,000)” ( 404 ). Then the deposit and withdrawal transactions are split into ranges wherein individual transaction amounts match and matching transactions are associated one-to-one ( 405 ), and the one-to-one correspondences of the deposit and withdrawal transactions are arranged in order of time of occurrence so as to generate fund transfer details between products by client ( 406 ). 
         [0064]    The following process is further explained by referring to  FIG. 7 . First a transaction data is loaded from Work table  3  (S 301 ). Second it is determined whether or not the transaction data is the end of data of the client (S 302 ). If not considered to be the end data of the client, it is determined whether or not it is a deposit transaction (S 303 ), and if considered to be a deposit transaction, then it is determined whether or not it is categorized as “other” (S 304 ). If not categorized as “other”, the transaction data is output to Deposit table  4  (S 305 ), which is followed by the stage S 301  to load the next transaction data. At the stage of S 304 , if categorized as “other”, then the transaction data is set to be “other deposit=other deposit+transaction amount” (S 306 ), which is followed by the stage S 301  to load the next transaction data. 
         [0065]    At the stage of S 303 , if the transaction data is not considered to be a deposit transaction, then it is determined whether or not the transaction data is categorized as “other” (S 307 ), and if it is not categorized as “other”, the transaction data is output to Withdrawal table  5  (S 309 ), which is followed by the stage S 301  to load the next transaction data. At the stage of S 307 , if the transaction data is categorized as “other”, then the transaction data is set to be “other withdrawal=other withdrawal+transaction amount” (S 308 ), which is followed by the stage S 301  to load the next transaction data. 
         [0066]    At the stage of S 302 , if the transaction data is determined as the end of data of the client, then the “other” deposit amount and the “other” withdrawal amount are compared (S 310 ), in order to form a dummy data defined as follows: 
         [0067]    When the other-withdrawal amount&gt;the other-deposit amount, the dummy data (other) is formed to be “the other-withdrawal amount=the other-withdrawal amount−the other-deposit amount” (S 311 ). Thereafter, the formed dummy data is output to Withdrawal table  5 , which is followed by the stage S 315 . 
         [0068]    When the other-withdrawal amount&lt;the other-deposit amount, the dummy data (other) is formed to be “the other-deposit amount=the other-deposit amount−the other-withdrawal amount” (S 313 ). Thereafter, the formed dummy data is output to Deposit table  4 , which is followed by the stage S 315 . 
         [0069]    When the other-withdrawal amount=the other-deposit amount, it is determined whether or not it is the end of Work table  3  (S 315 ), and if not considered to be the end, then it is followed by the stage S 301  to load the next transaction data. On the other hand, if it is considered to be the end, then the processing is to be completed. 
         [0070]    As described above, transactions within a specified period (e.g. two days) for another round of the computer program association function are output to either Deposit table  4  or Withdrawal table  5 , wherein a single dummy data within the same specified period is to be added. Accordingly, the dummy data that is formed on the first day is to be deleted, and the dummy data that is formed on the second day is to be kept. In sum, the fund transfer details of the first day are settled by the computer processing as follows: 
         [0071]    The transactions are output to either Deposit table  4  or Withdrawal table  5  and are matched in accordance with the processing shown in  FIG. 5 . Accordingly, the two-day fund transfer details are formed, and the processing of another round of the computer program association function is to be completed so that the fund transfer details of the first day can be fixed. Herein, it is possible to load the two-day transaction data from the journal logs which is followed by the processing shown in  FIG. 4  and  FIG. 5 , instead of conducting another round of the computer program association function. In regard to the specified period for the computer program association function or another round of the computer program association function, it is possible to set a longer period if required. 
         [0072]    Moreover, the two-step computer program association function is defined as iteration processing of the computer program association function in order to reorganize the fund transfer details so that they are more simplified. For example, when shifting funds from term deposit to investment fund, it is common to deposit funds into a deposit combined account for settlement for purchasing purposes. Generally when an investment fund is purchased, the funds for purchase are withdrawn from an ordinary deposit. The funds to purchase the investment cannot be withdrawn from a term deposit or come from cash payment. Therefore, the funds for purchase of the investment must be transferred to an ordinary deposit from the term deposit when purchasing an investment fund. 
         [0073]    In this respect, two types of association functions are needed, that is, “term deposit→ordinary deposit” and “ordinary deposit→term deposit”. However, in order for the association function “term deposit→investment fund” to be realized, a computer program association function must be conducted again for each ordinary deposit. In this way, the fund transfer details are simplified, since the products in which the funds only pass through are deleted because they are practically meaningless. 
         [0074]    The following is further explained by specifically referring to  FIG. 8 . First, the transaction history wherein the beneficiary is set to “ordinary deposit” ( 501 ) is added to the transaction history wherein the fund source is set to “ordinary deposit” ( 502 ), thereafter all of the transactions are arranged in chronological order and separated into deposits and withdrawals ( 503 ). The data “ordinary deposit (¥500,000)” on the deposit side and the data “ordinary deposit (¥300,000)” on the withdrawal side are matched so as to be offset by value, thereafter the remainder “ordinary deposit (¥200,000)” is allocated to the deposit side as a positive quantity ( 504 ). The deposit and withdrawal transactions are split into ranges wherein individual transaction amounts match and matching transactions are associated one-to-one ( 505 ), and the one-to-one correspondences of the deposit and withdrawal transactions are arranged in order of time of occurrence to generate fund transfer details between products by client ( 506 ). 
         [0075]    The following is further explained by referring to  FIG. 9 . First the transaction data is loaded from the Two-step association function work table  6  (S 401 ). Second it is determined whether or not transaction data is the end of data of the client (S 402 ), and if not considered to be the end data of the client, then it is determined whether or not it is a deposit transaction (S 403 ). If it is considered to be a deposit transaction, then it is determined whether or not it is related to “ordinary deposit” (S 404 ), and if it is not related to “ordinary deposit”, then the transaction data is output to the Two-step association function deposit table  7  (S 405 ), which is followed by the stage S 401  to load the next transaction data thereafter. At the stage of S 404 , if it is related to “ordinary deposit”, then the transaction data is set to be “ordinary deposit=ordinary deposit+transaction amount” (S 406 ), which is followed by the stage S 401  to load the next transaction data. 
         [0076]    At the stage of S 403 , if it is not considered to be the deposit transaction, it is determined whether or not it is related to “ordinary deposit” (S 407 ). If it is not related to “ordinary deposit”, then the transaction data is output to the Two-step association function withdrawal table  8  (S 409 ), which is followed by the stage S 401  to load the next transaction data thereafter. At the stage of S 407 , if it is related to “ordinary deposit”, the transaction data is set to be “ordinary withdrawal=ordinary withdrawal+transaction amount” (S 408 ), which is followed by the stage S 405  to load the next transaction data. 
         [0077]    At the stage of S 402 , if it is considered to be the end data of the client, then the deposit amount of the ordinary deposit and the withdrawal amount of the ordinary deposit are compared (S 410 ), in order to form the ordinary deposit data defined as follows: 
         [0078]    When the withdrawal amount of the ordinary deposit&gt;the deposit amount of the ordinary deposit, the ordinary deposit data is formed to be “the withdrawal amount on ordinary deposit=the withdrawal amount on ordinary deposit−the deposit amount on ordinary deposit” (S 411 ). Thereafter, the formed ordinary deposit data is output to Two-step association function withdrawal table  8  (S 412 ), which is followed by the stage S 415 . 
         [0079]    When the withdrawal amount of the ordinary deposit&lt;the deposit amount of the ordinary deposit, the ordinary deposit data is formed to be “the deposit amount of the ordinary deposit=the deposit amount of the ordinary deposit−the withdrawal amount of the ordinary deposit” (S 413 ). Thereafter, the formed ordinary deposit data is output to Two-step association function deposit table  7  (S 414 ), which is followed by the stage S 415 . 
         [0080]    When the withdrawal amount of the ordinary deposit=the deposit amount of the ordinary deposit, then followed by the stage S 415  directly. Thereafter, it is determined whether or not the end of Two-step association function work table  6  (S 415 ), and if not considered to be the end, then followed by the stage S 401  to load the next transaction data. On the other hand, if it is considered to be the end, then the processing is to be complete. 
         [0081]    Referring again to  FIG. 1 , the two-step association function deposit transaction data and the two-step association function withdrawal transaction data are split into ranges wherein individual transaction amounts match and matching transactions are associated one-to-one, and the one-to-one correspondences of deposit and withdrawal transactions are output to Transfer detail database  2  as fund transfer details between products by client ( 107  and  108 ). 
       EXPLANATION OF SYMBOLS 
       [0000]    
       
           1 . Transaction history database  1   
           2 . Transfer detail database  2   
           3 . Work table 
           4 . Deposit table 
           5 . Withdrawal table 
           6 . Two-step association function work table 
           7 . Two-step association function deposit table 
           8 . Two-step association function withdrawal table