WO2002065365A1 - Dispositif permettant l'integration de donnees de transaction relatives aux transactions financieres - Google Patents

Dispositif permettant l'integration de donnees de transaction relatives aux transactions financieres Download PDF

Info

Publication number
WO2002065365A1
WO2002065365A1 PCT/JP2002/000976 JP0200976W WO02065365A1 WO 2002065365 A1 WO2002065365 A1 WO 2002065365A1 JP 0200976 W JP0200976 W JP 0200976W WO 02065365 A1 WO02065365 A1 WO 02065365A1
Authority
WO
WIPO (PCT)
Prior art keywords
transaction information
data
record
aggregated
interest
Prior art date
Application number
PCT/JP2002/000976
Other languages
English (en)
French (fr)
Inventor
Shinsuke Yoshioka
Motoshi Asano
Masami Sakamoto
Tetsuya Anno
Original Assignee
Sony Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corporation filed Critical Sony Corporation
Priority to EP02711339A priority Critical patent/EP1359525A4/en
Publication of WO2002065365A1 publication Critical patent/WO2002065365A1/ja
Priority to US14/071,133 priority patent/US20140114821A1/en

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/12—Accounting
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q40/00—Finance; Insurance; Tax strategies; Processing of corporate or income taxes
    • G06Q40/02—Banking, e.g. interest calculation or account maintenance

Definitions

  • the present invention relates to an apparatus for aggregating transaction information relating to financial transactions, a method thereof, a recording medium storing a program for executing the apparatus, and a recording medium storing a program for executing the method. More specifically, transaction information is obtained from a device that stores transaction information on financial transactions, and developed data indicating cash flows is generated based on the data, and the developed data is processed under specified aggregation conditions.
  • the present invention relates to a technology capable of supplying aggregated data that accurately represents a cash flow to a risk management system by performing aggregation based on the data. Background technology
  • Interest rate risk (margins of interest and the value of assets held Value fluctuation risk), liquidity risk (risk of bankruptcy due to timing of inflow and outflow of funds, mismatch of amounts, etc.), currency risk (funds and liabilities on a yen basis due to fluctuations in exchange rates) It is generally known that the risk of change in value is included.
  • risk management systems that analyze cash flow information, calculate the amount of risk, hedges, etc., and support business decisions are introduced and used by many financial institutions.
  • An object of the present invention is to aggregate a huge number of pieces of cash flow information of, for example, several hundred thousand units into data that can be processed by a risk management system. Disclosure of the invention
  • the present invention has the following features.
  • the invention described in claim 1 stores the transaction information from the transaction information storage device. Acquisition, generating a development record indicating the occurrence of a monetary transfer amount based on the transaction information, grouping the development records based on predetermined aggregation conditions, and generating an aggregation record from a plurality of expansion records belonging to the same group I do.
  • the money transfer amount refers to the amount of money required for depositing and withdrawing principal, paying interest, and changing the loan balance.
  • the invention described in claim 2 has a transaction information aggregating unit provided for each ledger file stored in the transaction information storage device, and each transaction information aggregating unit is stored in the corresponding ledger file.
  • the predetermined aggregation condition is determined according to the nature of the financial product being used.
  • financial institutions handle a variety of financial products, and cash flows are generated daily for each financial product, but the conditions and content of the cash flows differ for each financial product.
  • cash flows are generated daily for each financial product, but the conditions and content of the cash flows differ for each financial product.
  • by providing an aggregation unit suitable for each financial product it is possible to collectively process risks for the financial products handled by the financial institution.
  • the invention according to claim 3 is characterized in that the transaction information aggregating unit generates a development record storing at least one change date of the principal, interest, and balance and the amount of the change, and Transactions that group expanded records based on aggregation conditions and generate aggregate records by adding at least one of the principal, interest, and balance of the grouped expanded records And information gathering means.
  • the development record stores at least one change date of the principal, interest, and balance and the amount of the change, so that it is possible to grasp an accurate cash flow amount on a daily basis.
  • the invention according to claim 6 is a development record that acquires transaction information from a transaction information storage device and generates a development record representing at least one change of the principal, interest, and loan balance based on the transaction information.
  • the method further comprises: a generation step; and an aggregated record generation step of grouping the expanded records based on a predetermined aggregation condition and generating one aggregated record from a plurality of expanded records belonging to the same group.
  • the amount of money transferred refers to the amount of money paid and received, payment of interest, and changes in the loan balance.
  • FIG. 1 is a block diagram for explaining a transaction information aggregating apparatus according to the present invention.
  • FIG. 2 shows an example of the configuration of the transaction information aggregator according to the embodiment.
  • FIG. 3 is a block diagram showing an example of the configuration of the ordinary deposit transaction information aggregating unit.
  • FIG. 4 is a diagram showing an example of the structure of a record in an ordinary account ledger file.
  • Fig. 5 is a diagram showing a scenario of an example of a transaction on ordinary deposits.
  • Figure 6 is a diagram showing the development data of ordinary deposits.
  • Fig. 7 is a diagram showing aggregated data of ordinary deposits.
  • FIG. 8 is a diagram showing the development data of ordinary deposits.
  • Fig. 9 is a diagram showing aggregated data of ordinary deposits.
  • FIG. 10 is a diagram showing the ordinary deposit development data.
  • Fig. 11 is a diagram showing aggregated data of ordinary deposits.
  • FIG. 12 is a diagram showing development data of ordinary deposits.
  • Figure 13 is a diagram showing aggregated data of ordinary deposits.
  • FIG. 14 is a diagram showing the development data of ordinary deposits.
  • Figure 15 shows the aggregated data of ordinary deposits.
  • Fig. 16 is a diagram showing the development data of ordinary deposits.
  • Fig. 17 shows aggregated data of ordinary deposits.
  • FIG. 18 is a diagram showing a configuration example of a time deposit transaction information aggregating unit.
  • FIG. 19 is a block diagram showing an example of the configuration of the regular deployment means and the regular aggregation means.
  • FIG. 20 shows an example of the structure of a record in a time deposit ledger file.
  • Fig. 21 is a diagram showing a scenario of a transaction example relating to term deposits.
  • FIG. 22 is a diagram showing time deposit development data.
  • Figure 23 is a diagram showing the aggregated data of time deposits.
  • '' Fig. 24 shows the time deposit development data.
  • Figure 25 is a diagram showing the aggregated data of time deposits.
  • Figure 26 is a diagram showing the time deposit development data.
  • Figure 27 shows the aggregated data of time deposits.
  • Figure 28 shows the time deposit development data.
  • Figure 29 shows the aggregated data of time deposits.
  • FIG. 30 is a diagram showing time deposit development data.
  • Fig. 31 is a diagram showing aggregate data of time deposits.
  • FIG. 32 is a diagram showing time deposit development data.
  • FIG. 33 is a diagram showing aggregated data of time deposits.
  • FIG. 34 is a block diagram showing a configuration example of a foreign exchange contract information processing means.
  • FIG. 35 is a diagram showing a scenario of a transaction example regarding time deposits.
  • FIG. 36 is a diagram showing an example of the details of the data acquired by the exchange contract data receiving unit from the time deposit ledger file.
  • FIG. 37 is a diagram for explaining the calculation performed in the purchase price / sale price calculation section.
  • FIG. 38 is a diagram showing an example of aggregated exchange contract information data generated by a purchase price / sale price calculation unit.
  • FIG. 39 is a diagram showing an example of aggregating the exchange contract information generated by the purchase price / sale price calculation unit.
  • FIG. 40 is a diagram showing an example of aggregated exchange contract information data generated by a purchase price / sale price calculation unit.
  • FIG. 41 is a diagram illustrating an example of aggregated data of exchange contract information generated by a purchase price / sale price calculation unit.
  • FIG. 42 is a block diagram showing a configuration example of a force-drawing transaction information aggregating unit.
  • Figure 43 is a diagram showing a scenario of a transaction example for a force drone.
  • FIG. 44 is a conceptual diagram showing an example of transaction information stored in a card loan ledger file.
  • FIG. 45 is a diagram showing an example of card loan development data.
  • FIG. 46 is a diagram showing an example of card loan aggregated data.
  • FIG. 47 is a conceptual diagram showing an example of transaction information stored in a card loan ledger file.
  • FIG. 48 is a diagram showing an example of force-drawing development data.
  • FIG. 49 is a diagram showing an example of aggregated card loan data.
  • FIG. 50 is a conceptual diagram showing an example of transaction information stored in a card loan ledger file.
  • FIG. 51 is a diagram showing an example of card loan development data.
  • FIG. 52 is a diagram showing an example of a card loan consolidation day.
  • Fig. 53 is a block diagram showing a configuration example of the purpose-specific loan / mortgage transaction information aggregator.
  • FIG. 54 is a block diagram showing a configuration example of the purpose-specific loan transaction information expanding means.
  • FIG. 55 is a block diagram showing a configuration example of the mortgage transaction information expanding means.
  • Figure 56 is a diagram showing the scenario of a transaction example of loans by purpose and mortgages.
  • FIG. 57 is a diagram showing the contents of the loan account used in the scenario shown in FIG.
  • Figure 58 shows development data for fixed interest rates.
  • Figure 59 is a diagram showing the development of floating interest rates.
  • Figure 60 shows the development of fixed interest rates.
  • Figure 61 is a diagram showing development data on floating interest rates.
  • FIG. 62 is a diagram showing expanded data relating to Cap.
  • FIG. 63 is a diagram showing an example of an aggregated data generated by the expanded data aggregating means for Cap.
  • FIG. 64 is a diagram illustrating an example of fixed-part aggregated data generated by the fixed-part aggregated data merger and passed to the risk management system.
  • FIG. 65 is a diagram showing an example of aggregated fluctuation data generated by the aggregated fluctuation data merger and passed to the risk management system.
  • FIG. 1 is a block diagram for explaining a transaction information aggregating apparatus according to the present invention.
  • the transaction information aggregating device 1 is an information processing device such as a computer or a workstation, and is generally connected so as to be able to acquire transaction information from a transaction information storage device 2 including a transaction information file included in an accounting system. Connected to the risk management system 3, the transaction information stored in the transaction information storage device 2 is aggregated and provided to the risk management system 3.
  • the information processing device that constitutes the transaction information aggregating device 1 is not necessarily physically one device, but each component is realized by one information processing device, and the transaction is performed as a set of these components.
  • the information aggregation device 1 may be configured.
  • the transaction information storage device 2 may be composed of a file that is a copy of the transaction information file included in the accounting system. More specifically, the contents of the transaction information file are stored in a file in the transaction information storage device 2 by, for example, a patch process or an online process at the end of a day's transaction. May be duplicated. Further, when the transaction information storage device 2 is configured from a duplicate file of the transaction information file, the duplicate file does not need to be linked to the transaction information file of the accounting system online and in real time, and will be described later. It is only necessary to back up data at intervals necessary for risk management, for example, by batching once a day.
  • transaction information refers to information relating to money transactions, and is a concept including, for example, information relating to various deposit transactions handled by banks and information relating to various account transactions.
  • transaction information file refers to a file in which transaction information is stored in a readable and writable manner, and is a concept that includes, for example, a general account ledger file, a time deposit ledger file, and various loan ledger files in a banking system.
  • risk management system refers to a system that manages risks related to the management of financial institutions, including interest rate risk, liquidity risk, and foreign exchange risk.For example, TSSummit of the United States Summit Inc. This is an example of a risk management system.
  • the risk management system 3 processes the aggregated transaction information and other transaction information supplied from the transaction information aggregating device 1 to determine various interest rates, execute simulations for changes in risk, etc. Risk management information is generated and provided by the display device 4 and the printing device 5.
  • the transaction information aggregating device 1 has a function of aggregating transaction information for use in risk management based on the transaction information stored in the transaction information storage device 2 and supplying this to the risk management system.
  • transaction information is acquired from the transaction information storage device 2, and based on the transaction information, an aggregation reference date (the date on which the transaction information aggregation device executes aggregation, or A development record that indicates the occurrence of cash flows after the cash movement and the aggregation reference date, and a plurality of deployments that are grouped based on predetermined conditions. It has a function to generate one aggregated record from records.
  • the transaction information aggregating device 1 functions to accurately store the information contained in one or a plurality of expanded records in the aggregated record, so that accurate information is provided to the risk management system, and the record processed by the risk management system is also processed.
  • the number, that is, the data amount can be reduced.
  • FIG. 2 is a block diagram showing a configuration example of the transaction information aggregating apparatus 1 according to the present embodiment.
  • a transaction information storage device 2 stores a plurality of transaction information files relating to different financial instruments, such as a general deposit ledger file 21, a time deposit ledger file 22, a card loan ledger file 23, and a purpose-specific loan ledger file. 24, has a mortgage ledger file 25.
  • the transaction information aggregator 1 has a general deposit transaction information aggregator 26, a term deposit transaction information aggregator 27, a card loan transaction information aggregator 28, and a purpose-specific loan 'home loan transaction aggregator 29'.
  • the ordinary deposit ledger file 21 is in the ordinary deposit transaction information aggregator 26, the time deposit ledger file 22 is in the time deposit transaction information aggregator 27, and the card account ledger file 23 is a card loan.
  • the transaction information aggregator 28 is connected to the purpose-specific mortgage file 24 and the housing account ledger file 25 to the purpose-specific mortgage / mortgage transaction information aggregator 29.
  • Each transaction information aggregator 26 to 29 supplies the risk management system 3 with aggregated data on the financial products handled by the corresponding ledger file.
  • the transaction information aggregator is provided for each ledger file because the conditions for generating cash flows differ for each financial instrument. This is to respond to this.
  • Each transaction information aggregator has the function of collecting transaction information to be used for risk management based on the transaction information stored in the transaction information file and supplying this to the risk management system 3.
  • the configuration and operation of each transaction information aggregator will be described below.
  • FIG. 3 is a block diagram showing a configuration example of the ordinary deposit transaction information aggregator 26 applied to the ordinary ledger file 21.
  • the ordinary deposit transaction information aggregating section 26 includes ordinary deposit transaction information expanding means 301 and ordinary deposit transaction information aggregating means 302.
  • the ordinary deposit transaction information expanding means 310 is composed of an ordinary deposit transaction information acquisition unit 303 connected to the ordinary deposit ledger file 21 and a cash movement connected to the ordinary deposit transaction information acquisition unit 303. It has a processing unit 304 and an interest cash / flow processing unit 303, and an ordinary deposit development data storage unit 300 connected to the processing units 304 and 310.
  • the ordinary deposit transaction information acquisition unit 303 has a function of acquiring data necessary for calculating the transfer of money from the ordinary account ledger file 21 for each record constituting the file.
  • FIG. 4 shows an example of the structure of a record in the ordinary account ledger file 21.
  • the record includes an account number field 401, a customer number field 402, a name field 400, a common management code group field 404, a passbook balance field 405, a last transaction date field 406, Chain address field 4 07, Transaction code field 4 08, Amount field 4 0 9, Handling date field 4 1 0, Description field 4 1 1, Chain address There are fields 4 1 2,.
  • the passbook balance field 405 records the balance of the savings account corresponding to the record
  • the transaction code field 408 stores deposits and withdrawals for the savings account.
  • a code is recorded to distinguish between transactions such as interest.
  • the amount field 409 stores the amount of the transaction
  • the handling date field stores the date on which the transaction was performed.
  • the address of the next part of the record is stored in the chain address 412, and a chain address field 412 is generated from the transaction code field 408 every time a transaction is performed, and is chained one after another. It forms one record.
  • the savings transaction information acquisition unit 303 stores data necessary for calculating the transfer of money, for example, the passbook balance field 405, the last transaction date field 406, the transaction code field 408, and the amount field. Acquires the data stored in 409, handling date field 410, etc.
  • the cash movement processing unit 304 acquires, for each record in the ordinary deposit ledger file 21, the principal and interest generated on the processing reference date. Generate a deployment record that records the change in
  • the interest cash flow processing unit 306 calculates the interest on the next interest day for each record in the ordinary ledger file 21 based on the data acquired by the ordinary transaction information acquisition unit 303 Then, this is stored in the development record and passed to the ordinary deposit development data storage unit 305.
  • the ordinary deposit development data storage unit 304 accumulates development records supplied from the cash movement processing unit 304 and the interest cash flow processing unit 303 and accumulates them as ordinary deposit development data.
  • Ordinary deposit development data the ordinary deposit transaction information development means 301 21 This is data that is a collection of all the ordinary deposit transaction information development records generated as a result of processing all the records in 1.
  • the ordinary deposit transaction information aggregating means 302 includes an aggregation target extraction unit 300 connected to the ordinary deposit development data storage unit 303 and an aggregation content calculation connected to the aggregation target extraction unit 303. It has a unit 308 and an ordinary deposit aggregated data storage unit 309 connected to the aggregated content calculation unit 308.
  • the aggregation target extracting unit 307 groups and extracts the group of ordinary deposit expanded data records that can be aggregated from the ordinary deposit expanded data storage unit 305 from the ordinary deposit expanded data storage unit 305.
  • “Aggregation” refers to development on the same cash flow date (principal-interest transfer date, prosperity date) and the same currency (yen, US dollar, euro, etc.) Organize records into one group so that they are aggregated into one aggregated record. For example, you can sort explosion records using the cash flow date and currency as keys, and if the cash flow date and currency are different from the previous record, use a different group. And so on.
  • the aggregation content calculation unit 308 sums up the transfer of principal, interest, and the next interest day for each group. Then, the data is stored in one aggregated record, and the aggregated record is sent to the ordinary deposit aggregated data storage unit 309. For an expanded record that does not belong to a group, one aggregated record is generated without summing and sent to the ordinary deposit aggregated data storage unit 309.
  • aggregated ordinary deposit data which is a set of aggregated records
  • the aggregated ordinary deposit data storage unit 309 accumulates the completed aggregated ordinary deposit data and stores the data. It functions to supply aggregated savings data to the risk management system3. It is desirable that the format of the aggregated record be in a format that conforms to the specifications of the risk management system 3.However, an interface (not shown) that converts the aggregate data of ordinary deposits into a format that conforms to the specifications of the risk management system 3 It is also possible to supply the risk management system 3 with the savings account aggregated data via the means.
  • Fig. 5 is a diagram showing a scenario of a transaction example regarding ordinary deposits.
  • a new account # 1 was opened on March 10, 2000, ⁇ 100,000 was deposited, a new account # 2 was opened, and ⁇ 1,500,000 Is deposited, a new account # 3 is opened, and 5,000, 000 yen is deposited. These rates are 0.05% per year.
  • another new account # 4 was opened, 800,000 yen was deposited, and $ 100,000 was purchased from account # 3. US $ 0.00 is deposited as a foreign currency savings account.
  • the yen-dollar exchange rate at this time is 109.00 yen / dollar.
  • 100,000 yen will be withdrawn from Account # 2 on April 28, but the withdrawal will be canceled the following day on 29th.
  • July 15 Account # 1 is closed.
  • a prolific day arrives on August 15 and interest is paid to all accounts.
  • FIG. 6 shows the data stored in the savings data storage unit 2005 after the processing by the cash and movement processing unit 304 and the interest cash and flow processing unit 303.
  • FIG. 7 is a diagram showing the ordinary deposit development data on the day 0, and FIG. 7 shows the ordinary saving development data generated by aggregating the ordinary deposit development data and stored in the ordinary deposit aggregated data storage unit 309; It is a figure which shows a deposit aggregation day.
  • the ordinary deposit development data consists of a plurality of development records R 601, R 602, R 603, R 604, R 605, R 606, and each record is an account Number field 6 01, Currency field 6 0 2, CF (cash flow) Occurrence date field 6 0 3, Deposit principal field 6 04, Withdraw principal field 6 0 5, Interest rate field 6 0 6 It has a balance field 607, an interest accumulation field 608, and an interest rate field 609.
  • the aggregate data of ordinary deposits shown in Fig. 7 is composed of aggregate records R701 and R702, and the aggregate record is composed of a product type field 711, an aggregate ID field 702, a currency field 703, It has a date field 704, a principal transfer amount field 705, an interest transfer amount field 706, and a balance field 707.
  • a code identifying the corresponding financial instrument is entered in the product type field.
  • Aggregate ID is an identifier that identifies aggregated savings data.
  • the savings data shown in Fig. 6 is generated as follows. First, when the ordinary deposit transaction information acquisition section 303 acquires data from the ordinary account ledger file 21 that records records records relating to accounts # 1 to # 3, the cash movement processing section 304 acquires the account. The fact that # 1 to # 3 were newly opened and payments were made on March 10th respectively was confirmed by the above-mentioned transaction code field 408, amount field 409, and transaction date field 410 (Fig. 4 ), And generate expanded records R601, R602, and R603.
  • Data acquired from the ordinary deposit transaction information acquisition unit 303 is stored in the fields of the account number, currency, CF occurrence date, and interest rate of the developed record.
  • the deposit amount of each account is stored in the deposit principal field 604 and the balance field 607 of the corresponding record.
  • the ordinary deposit transaction information acquisition section 303 determines whether or not it is necessary to enter the interest and interest amount 6 06 and the interest product number 6 08. In this case, it is not necessary, so expand it without entering it.
  • the interest cash 'flow processing unit 306 determines from the data of the ordinary deposit transaction information acquisition unit 303 that the account was newly opened on March 10, and since the deposit period is 0 days, the interest 0 yen expansion record R 6 0 4, R 6 0
  • R 606 is generated.
  • the ordinary deposit expanded data storage unit 304 accumulates ordinary deposit expanded data as shown in FIG. Regarding the amount of principal transfer, etc., which is the amount entered in the fields of the development record, “10” (correct) refers to the amount coming in from the bank, and “1” refers to the amount leaving the bank (Negative).
  • the ordinary deposit transaction information expanding means 301 instructs the ordinary ordinary deposit transaction information aggregating means 302 to start processing.
  • the aggregation target extracting unit 3007 obtains the ordinary deposit development data from the ordinary deposit development data storage unit 304 and composes the ordinary deposit development data. Grouping and extracting those that can be aggregated from multiple expanded records.
  • the grouping condition is that the records have the same CF occurrence date and the same currency development, and records that satisfy the aggregation condition are grouped.
  • the aggregation content calculation unit 308 receives, for example, R601 to R603 as one group.
  • the data of the deposit principal field 604 and the withdrawal principal field 605 of the three development records R 601 to R 603 are added together, and the principal transfer amount of the aggregated record Generate the data of the field 705, and add the data of the interest payment amount 60.6 field to generate the data of the interest transfer amount 706, and generate the data of the balance field 607.
  • the data of the balance field 707 is generated by summing up overnight, and a code is created and stored according to the target financial product and currency by referring to a conversion table (not shown) that indicates the product type and aggregation ID. By doing so, an aggregate record R701 is generated. Similarly, 604, R605, and R606 are made into one group, and these are aggregated as described above to generate an aggregate record R702.
  • the aggregated records R701 and R702 are accumulated in the ordinary deposit aggregated data storage unit 309, and supplied to the risk management system 3 as needed.
  • FIG. 8 is a diagram showing the expanded data of savings accounts with April 17 as a reference date
  • FIG. 9 is a diagram showing aggregated savings data of the same day.
  • the transaction information developing means 301 generates the ordinary deposit developing data shown in FIG. 8 in the same manner as the operation described with reference to FIGS.
  • the development data of savings account is the development record R 801 of account # 1, which is the development record of the principal and interest movements and the deposit balance on the base date of processing, generated by the cash movement processing unit 304.
  • An expansion record R 802 for account # 2 an expansion record R 803 and R 804 for account # 3, and an expansion record R 805 for account # 4.
  • the cash movement processing unit 304 stores the CF reference date field 803 of these expanded records in the field “203” indicating the processing reference date April 17, 2000 as “200 000 4 17”. ".
  • a new account # 4 was opened and 80,000 yen was deposited. $ 100,000 is purchased from Funds in Account # 3, and $ 100,000 is deposited as a foreign currency savings account.
  • the ordinary deposit transaction information expanding means 301 generates an expanded record as follows, thereby reflecting accurate transaction information in the expanded record. First, for the opening of new account # 4, a development record R805 is generated, and a development record R810 representing interest on the next prosperity date (August 15) is also generated. The purchase of $ 100,000 from the funds in Account # 3 is represented by the "1900 000" in the withdrawal principal field in development record R803. Also, a foreign currency savings deposit of $ 100,000 is represented by development record R804. Record R 804 contains the code “USD” in currency field 802 indicating that the currency is the US dollar.
  • the interest cash / flow processing unit 300 expands the expansion record R 806 relating to the account # 1, which is the expansion record relating to the next interest day, the expansion record R 807 relating to the account # 2, and the expansion relating to the account # 3.
  • the next interest rate day interest is stored in each of the development records R806 to R810 in the interest amount field.
  • the interest on the next interest day is equivalent to the interest from the previous interest date (or the account opening date if the first interest date has not yet arrived) to the processing date for the deposit balance on the reference date. I do.
  • the interest cash flow processor 306 writes “200000815” representing the next interest date August 15, 2000 in the CF occurrence date field of these records.
  • the transaction information aggregating means 302 groups the expanded records of the same currency and the same CF occurrence date in the same manner as described above, and aggregates the grouped expanded records into one aggregated record.
  • the savings development data R 8 0 1, R 8 0 2, R 8 0 3, R 8 0 5 that the currency is yen (JPY) and the cash flow occurrence date is April 17 is extracted as the aggregation target
  • the group is extracted as a first group by the group, and is aggregated into the aggregate record R 90 # by the aggregation content calculation unit 308.
  • the ordinary deposit development data R 804 showing the cash flow on April 1 for the currency “dollar” is extracted as the second group by the aggregation target extraction unit 307, and the aggregation content calculation unit 30 8 aggregated into an aggregated record R 902.
  • the general deposit development data showing the cash flow on August 15 R 806, R 807, R 808, R 810 is the aggregation target extraction unit 3 It is grouped and extracted as a third group by 07, and is aggregated into an aggregated record R903 by the aggregated content calculation unit 308.
  • the ordinary deposit development data R 809 showing the cash flow on August 15 for the currency “dollar” is extracted by the aggregation target extraction unit 307, and the aggregation record is calculated by the aggregation content calculation unit 308 It is collected in R904.
  • FIG. 10 is a diagram showing expanded ordinary deposit data generated by the ordinary deposit transaction information expanding means 301 when the processing reference date is April 28, and
  • FIG. 9 is a diagram showing consolidated ordinary deposit data generated by the ordinary deposit transaction information aggregating means 302 from the expanded data.
  • the interest cash / flow processing unit 303 calculates interest on the next interest welfare date (August 15) for each of the accounts # 1 to # 4, and develops a development record storing the calculated interest. R1006-R1010 are generated.
  • the generated expanded records R 1001 to R 1001 are stored as ordinary deposit expanded data in the ordinary deposit developed data storage unit 305.
  • the generation of aggregated savings data shown in FIG. 11 is performed by the grouping unit extracting unit 307 based on the expanded ordinary deposit data stored in the expanded ordinary deposit data storage unit 305 in the same manner as described above. This is performed in the same manner as described above by generating an aggregated record by the conversion and aggregation content calculation unit 308.
  • the cash flow of withdrawal of 100,000 yen from account # 2 is reflected in the principal transfer amount field of the aggregated record Rl101.
  • FIG. 12 is a diagram showing the ordinary deposit expanded data generated by the ordinary deposit transaction information expanding means 301 when the processing reference date is April 29, and
  • FIG. 9 is a diagram showing consolidated ordinary deposit data generated by the ordinary deposit transaction information aggregating means 302 from the expanded ordinary deposit data.
  • the interest cash 'flow processing unit calculates the next interest welfare date (August 15) for each of the accounts # 1 to # 4, and a development record R1 206 storing the calculated interest. ⁇ R 1 2 1 0 is generated.
  • the generation of aggregated savings data shown in FIG. 13 is performed by the grouping unit 307 based on the expanded ordinary deposit data stored in the expanded ordinary deposit data storage unit 305 in the same manner as described above. This is performed in the same manner as described above by generating the aggregated record by the aggregated content calculation unit 308, and the aggregated records R1301 to R1304 are generated.
  • the cash flow of canceling the withdrawal of 100,000 yen from account # 2 is reflected in the principal transfer amount field and balance of the aggregated record R.1301.
  • FIG. 14 is a diagram showing the ordinary deposit development data generated when the processing reference date is set to July 15 and
  • FIG. 15 is a diagram showing ordinary deposit transaction information from the ordinary deposit development data.
  • FIG. 9 is a diagram showing aggregated ordinary deposit data generated by an aggregation unit 302.
  • the interest cash flow processor 306 calculates the next interest rate date (August 15) for the accounts # 2 to # 4 excluding the canceled account # 1, and calculates the interest. Generates an expanded record R 1406 to R 1409 in which the generated interest is stored in the outgoing interest amount field. Since the account # 1 has been canceled, the interest cash flow processor 306 does not generate cash flow (interest payment) savings development data for the account # 1.
  • the developed records R1401 to R1409 generated as described above are stored as ordinary deposit developed data in the ordinary deposit developed data storage unit 305.
  • the generation of aggregated savings data shown in FIG. 15 is performed by the aggregation target extraction unit 307 based on the unfolded ordinary deposit data stored in the unfolded ordinary deposit data storage unit 305 in the same manner as described above. This is performed in the same manner as described above by generating an aggregated record by the grouping and aggregation content calculation unit 308.
  • the cash flow of principal payment and interest payment of 100,000 yen from Account # 1 is reflected in the principal transfer amount field of the aggregated record R1551.
  • FIG. 16 shows the processing performed by the ordinary deposit transaction information development means 301 when the processing reference date was set to August 15th.
  • FIG. 17 is a diagram showing the ordinary deposit development data generated by the ordinary deposit transaction information aggregating means 302 from the ordinary deposit development data. It is.
  • August 15 is the prime date when interest is fixed and paid for all savings accounts.
  • the ordinary deposit transaction information acquisition unit 304 acquires the data from the ordinary ledger file 21
  • the cash movement processing unit 304 determines that the cash flow (interest payment, settlement) has occurred. Then, the development records R 1601, R 1602, R 1603, and R 1604 that store the interest amount paid in the outgoing interest amount field are generated.
  • the interest cash flow processing unit 306 sets the development record R 166 5 corresponding to February 15th, 2001, which is the next interest day when the interest amount is stored in the interest amount field. , R 166, R 166, R 166 are generated for the accounts # 2 to # 4.
  • the generation of the aggregated savings data shown in Fig. 17 is based on the grouping and aggregation contents by the aggregation target extraction unit 307 based on the ordinary deposit development data stored in the ordinary deposit development data storage unit 305.
  • the calculation is performed in the same manner as described above by generating the aggregated record by the calculation unit 308.
  • the aggregation content calculation unit 308 performs processing so that the amount in which interest is incorporated into the balance is stored in the balance field of the aggregation record.
  • the generated expanded records R1701 to R1704 are stored in the ordinary deposit aggregated data storage unit 309 as ordinary ordinary deposit data.
  • aggregated savings data that accurately represents the processing reference date and cash flows to be generated in the future is generated, and the aggregated savings data of the ordinary deposit is significantly larger than the original transaction information in the number of transactions. Data has decreased.
  • aggregated data of ordinary deposits it is possible to Any very large number of cash flows can be handled by the risk management system.
  • the time deposit transaction information aggregating unit 27 includes time deposit transaction information development means (hereinafter abbreviated as “time development method”) 1801 and time deposit transaction information aggregator (hereinafter referred to as the time deposit information aggregation means). , Abbreviated as “periodical aggregation means”) 1802, and a foreign currency fixed-term deposit exchange reservation information processing means (hereinafter abbreviated as “reservation processing means”) 1803.
  • the time expansion means 18001 functions to receive time deposit transaction information data from the time deposit ledger file 22 and generate and output time deposit expansion data based on the transaction information data.
  • the term aggregation means 1802 receives the time deposit development data from the time development means 1801, generates the term deposit aggregation data based on the development data, and outputs the data to the risk management system 3. .
  • the reservation processing means 1803 receives the foreign exchange deposit data relating to the cancellation of the foreign currency deposit from the time deposit ledger file 22 and generates aggregated foreign exchange information based on the foreign exchange deposit data. Functions to output to management system 3.
  • foreign exchange contract means that a certain foreign currency amount is scheduled to be exchanged at the currency exchange rate on a specific day before the maturity date of a foreign currency deposit. If the ledger file does not include a foreign currency deposit, the reservation processing means may not be provided.
  • FIG. 19 is a block diagram showing an example of the configuration of the regular deployment means 1801 and the regular aggregation means 1802.
  • the periodical expansion means 18001 is composed of a time deposit transaction information acquisition section 1901 connected to the time deposit ledger file 22 and a cash movement processing section 1 connected to the transaction information acquisition section 1901. It has a cash flow processor 9003 and a principal and other cash flow processor 1903, and a developed data storage 1904 connected to the processors 1902 and 1903.
  • the transaction information acquisition unit 1901 acquires data necessary for calculating the transfer of money from the time deposit ledger file 22 for each record constituting the file.
  • FIG. 20 shows an example of the record structure of the time deposit ledger file 22.
  • the record includes a time code field 2001, which indicates the term of the time deposit, automatic cancellation, automatic cancellation, etc. Since it contains the type code field 2000 that indicates the type, the deposit / withdrawal processing unit 32 processes elements specific to time deposits such as the maturity of time deposits, their automatic continuation, and automatic cancellation by referring to these. it can.
  • the transaction information acquisition unit 1901 has a function of reading necessary data for each record and passing it to the cash movement processing unit 1902 and the cash flow processing unit 1903 such as principal.
  • the cash movement processing unit 1902 records the principal and interest fluctuations that occurred on the base date of processing based on the data acquired by the transaction information acquisition unit 1901, for each record in the time deposit ledger file 22. Generate the recorded time deposit development record.
  • the principal and cash processing unit 1903 calculates the principal and interest for each record in the time deposit ledger file 22 based on the data acquired by the transaction information acquisition unit 1901. Funds on the day when the amount fluctuates (maturity, interest payment date) It has the function of calculating the amount of money and interest and the balance of the deposit, storing these in the development record, and passing it to the fixed-term deposit development data storage unit 1904.
  • the time deposit development data storage unit 1904 stores the records supplied from the cash movement processing unit 1902 and the principal and other cash flow processing unit 1903 and stores the time deposit development data. To form When the time deposit transaction information developing means 18001 processes all the records in the time deposit ledger file 22, the time deposit expanded data is completed.
  • the term deposit transaction information aggregating means 1802 includes an aggregation target extraction section 1905 connected to the time deposit development data storage section 1904 and an aggregation connected to the aggregation target extraction section 1905. It has a content calculator 1906 and a term deposit aggregated data accumulator 1907 connected to the aggregated content calculator 1906.
  • the aggregation target extraction unit 1905 has a function of grouping and extracting, from the time deposit expanded data storage unit 1904, records that can be aggregated from the time deposit expanded data records. Aggregation uses development records for the same cash flow date (including principal and interest fluctuation dates, new account opening dates, maturity dates, and interest payment dates) and the same currency (yen, US dollars, unity, etc.). It works to aggregate into one aggregated record.
  • the developed records are sorted by cash flow occurrence date and currency, and if the cash flow occurrence date and currency are different from the previous record, another method is used. It is realized by grouping.
  • the aggregated content calculation unit 1906 receives the grouped records from the aggregation target extraction unit 1905, the aggregated principal, interest, and deposit balances of each group are summed up, and It is stored in an aggregated record, and functions to send the aggregated record to the term deposit aggregated data storage unit 1907.
  • a function to generate one aggregated record without adding them up and send the aggregated record to the time deposit aggregated data storage unit 1907 is provided.
  • the processing is performed for all the groups, and the time-deposit consolidated data set, which is a set of consolidated records, is completed. Functions to feed system 3.
  • the format of the aggregated record is a format that conforms to the specifications of the risk management system 3 , but an unillustrated interface that converts the aggregate data of time deposits into a format that conforms to the specifications of the risk management system 3 is not shown.
  • Aggregated time deposit data may be supplied to the risk management system 3 via one-face means.
  • FIG. Figure 21 is a diagram showing a scenario of a transaction example regarding time deposits.
  • Account # 1 has a deposit of 1,000,000 yen, a six-month fixed deposit, with an applicable interest rate of 0.12%, and automatic principal and interest renewal type.
  • Account # 2 has a deposit of 3,000 , 000 yen, two-year term deposit, 0.15% applicable interest rate, interest payment type, automatic cancellation type.
  • Account # 3 is a deposit of 2, '000, 000 yen, a three-month time deposit with a rate of 0.12%, and an automatic principal transfer type.
  • New Account # 4 has a deposit of 50,000 yen, a two-year term deposit, an applicable interest rate of 0.15%, and an automatic cancellation type.
  • Account # 3 expires and interest payments and principal renewal continue.
  • account # 5 was deposited The amount is 1,000,000 yen, March time deposit, applicable rate is 0.12%, and automatic cancellation type.
  • Another new account # 6 is a foreign currency term, with a deposit of 100,000 USD, a three-month foreign currency term deposit, an applicable interest rate of 4.45860%, and an automatic cancellation type.
  • Account # 1 expires, the account continues to pay interest and interest, Account # 3 also expires and is terminated, and Account # 5 also expires, and the account is terminated. # 6 also expires and will be canceled.
  • Account # 1 expires and is terminated, and interest payment is made on Account # 2.
  • Account # 2 expires on March 10, 2002, and Account # 4 expires on April 17, 2012.
  • FIG. 22 is a diagram showing the time-deployment data generated by the time-deposit transaction information development means 1801 on March 10, 2000
  • FIG. 23 is a diagram showing time-deposit transaction information on the same day.
  • FIG. 9 is a diagram showing time deposit aggregated data generated by an aggregation means 1 802.
  • the time deposit development data shown in Fig. 22 consists of a plurality of development records R2201 to R2207, each of which contains an account number field 2201, a currency field 2202, and CF (cash flow) generation.
  • the aggregated time deposit data shown in Fig. 23 is composed of aggregated records R2301 to R2305, and each aggregated record has a product type field 2301, an aggregated ID field 2302, It has a currency field 2303, a date field 2304, a principal transfer amount field 2305, an interest transfer amount field 2306, and a balance field 23007.
  • Product Type Feel In the field a code identifying the corresponding financial instrument is entered.
  • the aggregation ID is an identifier for identifying the aggregation data.
  • the unfolding data shown in Fig. 22 is generated as follows. First, when the time deposit transaction information acquisition unit 1901 acquires data from the ledger file 2 2, the cash movement processing unit 1902 opens accounts # 1 to # 3, and on March 10 It is determined from the record corresponding to each account in the ledger file 22 that the payment has been made, and the developed records R2201, R2202, and R2203 are generated. Account number field 222, currency field 222, CF occurrence date field 2203, and interest rate field 22009 store the data obtained from the ledger file. The amount is stored in the deposit principal field 222 and the balance field 222 of the corresponding record.
  • the principal and other cash flow processing section 1903 sets the development record R 2 2 that indicates the cancellation of the maturity date of each account and the payment of interest as the principal and interest fluctuation date of accounts # 1 to # 3. 0 to R2207 are generated.
  • the principal and cash flow processing unit 1903 calculates the principal paid by termination, the interest paid upon termination, and the interest paid on the interest payment date. The calculated values are stored in 2 205, Interest Interest Amount Field 220 6, and Balance Field 220 7.
  • Each expanded record is passed to the expanded data storage section 1904.
  • the expanded data storage unit 1904 accumulates expanded data as shown in FIG.
  • the regular deployment unit 1801 instructs the regular aggregation unit 1802 to start processing.
  • the regular aggregation means 1802 retrieves the developed data from the developed data storage section 1904 by the aggregation target extracting section 1905.
  • the records that can be aggregated among the records included in the expanded data are grouped and extracted.
  • development records of the same currency and the same CF occurrence date are grouped.
  • the expanded records R2201, R2202, and R2203 have the same currency and the same CF occurrence date, so these three records constitute one aggregated record.
  • the aggregated content calculation section 1906 receives these three records as one group, and sums the data of the deposit principal field 2204 and the withdrawal principal field 2205 to form the principal. Generate the data of the transfer amount field 2305, add the data of the interest outflow amount 2 206 field and generate the data of the interest transfer amount 2303, and the balance field 2202
  • the data of the balance field 2307 is generated by summing up the data of the balances, and the product type and aggregation ID are created by referring to the conversion table (not shown) and a code is created and stored according to the target financial product and currency. As a result, an expansion record R2301 is generated.
  • aggregated records R2301 to R2305 are accumulated as aggregated data in the aggregated data storage unit 1907, and supplied to the risk management system 3 as needed. It is preferable that the format of the aggregated record is a format that conforms to the specifications of the risk management system 3, but the aggregated data is converted to a format that conforms to the specifications of the risk management system 3. Consolidated to risk management system 3 via interface means Data may be supplied.
  • Time deposit expanded data is generated by 1801
  • time deposit integrated data is generated by time deposit transaction information aggregating means 1802 based on the time deposit expanded data.
  • Fig. 24 shows the time deposit development data generated when April 17, 2000 is the processing base time
  • Fig. 25 shows the time deposit aggregate data on the same day
  • Fig. 26 shows the time deposit development data on June 10, 2000
  • Fig. 27 shows the time deposit aggregate data on the same day
  • Fig. 28 shows the expanded data of time deposits on September 10, 2000
  • Fig. 29 shows aggregated data of time deposits on the same day.
  • Fig. 30 shows the time deposit development data on March 10, 2001
  • Fig. 31 shows the time deposit aggregation data on the same day.
  • Fig. 32 shows the development of fixed-term deposits on April 17, 2001
  • Fig. 33 shows the consolidated data of fixed-term deposits on the same day.
  • the term deposit aggregated data that accurately represents the cash flow that will occur in the future on and after the processing reference date is generated.
  • the number of cases is much smaller than the information.
  • FIG. 4 is a block diagram showing a configuration example of a reservation processing means 1803.
  • the reservation processing means 1803 receives the exchange reservation data receiving section 3401 which receives data relating to the exchange reservation from the time deposit ledger 'file 22 and the output of the receiving section 3401.
  • the received purchase price and sale price calculation unit 3402 and the exchange reservation aggregated data storage unit 3404 that receives the output of the calculation unit 3402 and transfers the foreign exchange summary data to the risk management system 3 Have.
  • the Exchange Receipt Data Overnight Receiving Section 3401 reads the data in the time deposit ledger file, and extracts the data related to each exchange contract, such as the maturity date, reserved date, reserved transaction amount (foreign currency), and reserved rate. Then, it has a function to output this.
  • the purchase price and sales price calculation section 3402 calculates the purchase price (refers to the reservation transaction amount and its interest amount), sale price (purchase amount, Etc.), and a function to generate a foreign exchange information aggregated record that stores these values for each foreign exchange contract.
  • the exchange contract information aggregated data storage unit has a function of accumulating exchange contract information aggregated data that is a collection of aggregated exchange contract information records.
  • FIG. 35 is a diagram showing a scenario of a transaction example regarding time deposits.
  • the scenario has the following contents. On March 10, 2000, Account # 1 was newly opened with a deposit of US $ 1,000,000. On March 11 the same year, Account # 2 was newly opened with a deposit of $ 500,000. On August 25 of the same year, a foreign exchange reservation was made for Account # 1, with a reservation amount of US $ 10,000 and a reservation rate of 107.50 yen. On August 26, a foreign exchange reservation was made for Account # 2 at a reservation amount of US $ 500,000 and a reservation rate of 106.98 yen. August 27 of the same year A foreign exchange reservation was made for Account # 1 at a reservation amount of US $ 50,000 and a reservation rate of 107.00 yen.
  • the exchange reservation data overnight receiving unit 3401 extracts data on the exchange contract from the time deposit ledger file 22 and receives it.
  • FIG. 36 shows an example of the contents of the data acquired by the exchange reservation data receiving section 3401 from the time deposit ledger file 22.
  • the exchange reservation data receiving unit 340 0 1 uses the currency, deposit amount (foreign currency), exchange rate, interest rate, deposit date, deposit period, expiration date, reservation date, We have received reservation amounts and reservation rates.
  • deposit amount foreign currency
  • exchange rate interest rate
  • deposit date deposit period
  • expiration date reservation date
  • the purchase price / sale price calculation unit 3402 receives the data on the foreign exchange contract as shown in FIG. 36 from the exchange reservation data overnight receiving unit 3401, and based on the data, Perform calculations, etc.
  • FIG. 37 is a diagram for explaining the calculation performed in the purchase price / sales value calculation section 3402.
  • the purchase price-sell price calculation unit 3402 creates one record for each exchange contract. Each record consists of a product type field 3701, an aggregate ID field 370, a buy currency field 370, a sell currency field 370, a date field 370, and a purchase amount field 370. 06, with a sales amount field of 3 0 7.
  • the purchase price / sale price calculation section 3402 enters the code that identifies the financial instrument corresponding to the product type field, and enters the code in the aggregate ID field. Enter an identifier to identify the foreign exchange reservation information aggregated data, enter a code indicating the type of foreign currency in the Buy Currency field, enter a code indicating Japanese currency in the Sell Currency field, and enter a code in the Buy Amount field. Enter the reservation amount, and in the sales amount field, calculate and enter the amount when the amount entered in the purchase amount field is exchanged for the selling currency at the reservation rate.
  • the purchase price / sale price calculation unit 3402 integrates the records to generate exchange reservation information aggregate data.
  • the purchase price / sales price calculation unit 3402 which groups and extracts those records that can be aggregated from among the above records, and sums the purchase price and sale price values of records belonging to the same group into one Make an aggregated record.
  • the grouping condition is to group records with the same date of occurrence of CF and the same buying currency and selling currency.
  • the expanded records R 3 701, R 3 7 0 3, and R 3 7 0 4 have the same currency and the same CF occurrence date, so these three records constitute one group.
  • Fig. 38 to Fig. 41 show examples of aggregated data of foreign exchange contract information generated by the purchase price / sales calculation unit 3402.
  • Fig. 38 shows the aggregated data of exchange reservation information when the reference date for processing is set to August 25, 2000.
  • the purchase price / sale price calculation unit 3402 generates only the record R3701, and this record is subject to aggregation.
  • the exchange reservation information aggregated data contains the record R380. Only 0 1 will be included.
  • Fig. 39 shows the aggregated data of exchange reservation information when the processing reference date is August 26, 2000.
  • the purchase price / sale price calculation section 3402 generates the records R3701, R3702, and these two records are subject to aggregation.
  • Fig. 40 shows the aggregated data of exchange reservation information when the processing reference date was August 27, 2000.
  • the purchase price / sale price calculation unit 3402 generates records R 3701, R 3702, and R 3703, and these three records are subject to aggregation.
  • the exchange contract information aggregated data includes record R4001 in which records R3701 and R3703 are aggregated, and R402 in which records R3702 are aggregated. .
  • Fig. 41 shows aggregated data of foreign exchange contract information when the reference date for processing is September 2, 2000.
  • the purchase price / sales value calculation unit 3402 generates records R3701, R3702, R3703, and R3704, and these four records are subject to aggregation.
  • records R 3101, R 3703 and R 3704 were consolidated, and record R 4101 and record R 3702 were consolidated.
  • R4102 will be included.
  • These aggregated exchange contract information records are accumulated as aggregated exchange contract data in the aggregate exchange reservation data storage unit 3403, and are supplied to the risk management system 3 as necessary. It is preferable that the format of the aggregated record conforms to the specifications of the risk management system 3, but an interface (not shown) for converting the aggregated data into a format that conforms to the specifications of the risk management system 3.
  • the exchange contract aggregation data may be supplied to the risk management system 3 via the.
  • aggregated foreign exchange forward contract data that accurately represents the cash flow of both foreign and Japanese currency that will occur in the future (maturity date) is generated, and the aggregated data is much larger than the original transaction information. ⁇ Data volume is decreasing.
  • the risk management system can be used for cash flows that are extremely large, such as so-called retail transactions. System.
  • a configuration example of the card loan transaction information aggregating unit 28 for aggregating transaction information recorded in the card loan ledger file 23 will be described with reference to FIG.
  • the card loan transaction information aggregating unit 28 includes card loan transaction information expanding means (hereinafter abbreviated as “card loan expanding means”) 4201 and card loan transaction information aggregating means (hereinafter referred to as “card loan expanding means”). , Abbreviated as “card loan consolidation means”).
  • the force-drawing developing means 4201 functions to receive card loan transaction information data from the card loan ledger file 23, generate and output card loan development data based on the transaction information data.
  • the force draw aggregation means 4202 receives the force draw development data from the card loan development means 4201, generates a card loan aggregation data based on the development data, and uses this as a risk. Functions to output to management system 3.
  • the card loan developing means 4 201 comprises a card loan transaction information acquisition section 4 203 connected to the card aperture ledger file 23, and a transaction information acquisition section 4 2 Cash / movement processing unit 4 2 0 4 and interest cash flow processing unit 4 206 connected to 0 3, and development data storage unit 4 connected to the processing units 4 204 and 4 206 205.
  • the transaction information acquisition section 4203 stores data necessary for calculating the transfer of money from the card loan ledger file 23 as one of the constituent files of the file. For each record.
  • the records in the card loan ledger file 23 include account number, interest rate, contract repayment date, repaid amount each time, refund, repayment interest, loan balance, next balance product number, next interest amount, next repayment date, last update Includes days.
  • the transaction information acquisition unit 4203 has a function of reading out necessary data for each record and passing the data to the cash movement processing unit 4204 and the interest cash flow processing unit 4206.
  • the cash movement processing unit 424 is based on the data acquired by the transaction information acquisition unit 423 for each record in the card loan ledger file 23, and the principal generated on the processing base date. Generates a force-drain deployment record that records interest and interest fluctuations, and the loan balance on the processing reference date.
  • the interest cash ⁇ It has the function of calculating the interest amount, storing this in the development record, and passing it to the card-lone development data storage section 425.
  • the force drone development data storage unit 4205 stores the records supplied from the cash / movement processing unit 4204 and the interest cash / flow processing unit 4202 and stores the card loan development data. It has the function of storing as.
  • the force draw transaction information developing means 4201 processes all the records of the card loan ledger file 23, the card loan developed data is completed.
  • the card loan transaction information aggregating means 4 202 is connected to the aggregation target extraction unit 4207 connected to the card loan development data overnight storage unit 4205 and the aggregation target extraction unit 4207. 9 ′, and an aggregated content calculation unit 4208 and a card loan deposit aggregated data storage unit 4209 connected to the aggregated content calculation unit 4208.
  • the aggregation target extraction unit 4207 has a function of extracting, from the card loan development data storage unit 4205, the group of records of card loan development data that can be aggregated and extracting them. Aggregation functions to aggregate deployment records for the same cash flow—the date of occurrence (including the base date for processing) —into one aggregation record. As a method of grouping, for example, the development records are sorted using the cash flow occurrence date as a key, and if the cash flow occurrence date is different from the previous record, it is realized by another group.
  • the aggregated content calculation unit 4208 receives the group of records from the aggregation target extraction unit 4207, the aggregated principal, interest, and deposit balances of each group are summed up. It is stored in one aggregated record and functions to send the aggregated record to the card loan aggregated data storage unit 4209. For unfolded records that do not form a group, the function is to generate one aggregated record without performing summation and send it to the card loan aggregated data storage unit 4209.
  • the processing is performed for all groups, and the aggregated card loan data, which is a set of aggregated records, is completed.
  • the aggregated card loan data storage unit 4209 stores the completed aggregated card loan data, and stores the accumulated card loans. It functions to supply the aggregated data to the risk management system 3. It is desirable that the format of the aggregated record be in a format that conforms to the specifications of the risk management system 3.However, an interface means (not shown) that converts the card loan aggregate data into a format that conforms to the specifications of the risk management system 3 is provided.
  • the drone aggregated data may be supplied to the risk management system 3 via the Internet.
  • Figure 43 is a diagram showing a scenario of a card drone transaction example.
  • the amount of borrowing for account # 1 was 200,000 yen
  • the contracted interest rate was 9.00%
  • the contractual repayment date was 12 days
  • each repayment was 20
  • a card account with a condition of 000 yen is generated
  • the loan amount of loan account # 2 is 100,000 yen
  • the contract interest rate is 9.00%
  • the contract repayment date is 27 days
  • the repayment amount is 20,000 each time.
  • a yen is generated, and thereafter, repayment is made on loan account # 1 on the 12th of every month, and repayment is made on account 27 of the monthly account on the 27th of every month.
  • FIG. 44 is a conceptual diagram showing an example of transaction information stored in the card loan ledger file 23 on February 10, 2000
  • FIG. 45 is a diagram showing card loan development on the same day.
  • FIG. 46 is a diagram showing force-drow development data generated by the means 420 1, and FIG. 46 shows a card-row aggregation data generated by the force-drain aggregation means 42 02 on the same day.
  • FIG. 46 is a diagram showing force-drow development data generated by the means 420 1
  • FIG. 46 shows a card-row aggregation data generated by the force-drain aggregation means 42 02 on the same day.
  • the expanded data shown in Fig. 45 consists of a plurality of expanded records R4501, R4502, R4503, and R4504, each of which has an account number field of 4501 and a currency field.
  • the card loan aggregate data consists of aggregate records R4601, R4602, R4603, and R4604. Each aggregate record consists of a product type field 4601, an aggregate ID field 4602, and a currency field. 46 03, repayment date code field 46 04, date field 460 5, principal transfer amount field 46 0 6, interest transfer amount field 460 7, balance Field 468. In the product type field, a code identifying the corresponding financial product is entered.
  • the aggregation ID is an identifier for identifying the card loan aggregation data.
  • the transaction information acquisition unit 4203 acquires the data as shown in FIG. 44 from the drone ledger file 23.
  • the cash movement processing unit 4202 determines that a loan with a debt of 200,000 yen has been generated for account # 1, based on the data of the force-drawing transaction information acquisition unit 4203. Then, generate an expansion record R4501. Similarly, it determines that a loan with a borrowed money of 100,000 yen has been generated for account # 2, and generates an expansion record R4502. Corresponding data is entered in the fields of each record by the cache movement processing unit 4202.
  • the interest cash 'flow processing unit 4 206 generates an expansion record R 4 0 3 relating to the next repayment date of account # 1, and generates an expansion record R 4 504 relating to the next repayment date of account # 2.
  • the interest amount calculated by the interest cash flow processing unit may be entered in the record, and the card account transaction information acquisition unit 4203 may use the ledger file as shown in Fig. 44.
  • the interest amount may be obtained from the interest cash and the interest amount may be copied to the record by the flow processing unit.
  • the expanded records R 4 501 to R 4504 generated as described above are passed from the processing units 4 204 and 4 206 to the expanded data storage unit 4 205,
  • the expanded data storage unit 420 stores this.
  • the card loan aggregating means 4202 groups and extracts, from the expanded data storage section 4205, those which can be aggregated among the expanded data record groups by the aggregation target extracting section 4207.
  • the development record of the same CF occurrence date, the same currency and the same since there are no two or more expanded records that satisfy this condition, no grouping is performed in the aggregation target extraction unit 4207, and the expanded records R4501, R4502, Aggregated records R4601, R4603, R4602, and R4604 corresponding to R4503 and R4504, respectively, are calculated by the aggregate content calculation unit 4208. It is generated and becomes the force data aggregated data shown in Fig. 46.
  • the principal transfer amount and the interest transfer amount are summed up by the consolidation content calculation unit 428, and the principal transfer amount field 460, interest of the consolidated record is added. This is entered in the transfer amount field 4607 and the balance field 4608.
  • FIG. 47 is a conceptual diagram showing an example of transaction information stored in the card loan ledger file 23 on March 12, 2000, and FIG. It is a figure which shows the expansion
  • FIG. 50 is a conceptual diagram showing an example of transaction information stored in the card loan ledger file 23 on March 27, 2000
  • FIG. Fig. 52 is a diagram showing the development data generated by the card loan development means 4201 in Fig. 52.
  • Fig. 52 is a diagram showing the card loan aggregation data generated by the card loan aggregation means 4202 on the same day. is there.
  • card loan aggregate data that accurately represents the processing reference date and future cash flows for card loan transactions is generated.
  • the aggregated data has significantly reduced the number of transactions and data volume compared to the original transaction information.
  • a very large number of cash flows such as so-called retail transactions can be processed by the risk management system.
  • the purpose-specific loan / housing unit transaction information aggregating unit 29 which aggregates transaction information relating to purpose-built loans such as car loans, pridal's loans, travel loans, and mortgages, will be described.
  • FIG. 53 is a block diagram showing an example of the configuration of the purpose-specific loan / housing unit transaction information aggregation unit 29.
  • loan-by-purpose ⁇ Mortgage transaction information aggregator 29 is a means for developing loan transaction information by purpose 5 3 0 1 for aggregating transaction information related to loans by purpose 5 0 2, fixed-part development data aggregation means 5 3 0 3, and variable-part development data aggregation means 5 3 0 4, and mortgage transactions to aggregate transaction information on housing units
  • Information development means 5 3 0 6, fixed / floating / cap deployment data distribution means 5 3 0 7, fixed-part development data aggregation means 5 3 0 8, and variable-part development data aggregation means 5 3 0 9 And a means for integrating and decompressing the data for the Cap component, and a means for merging the data for fixed-content aggregation 530 and the means for merging the variable-content aggregated data 53011.
  • the purpose-specific loan development means 53301 receives the purpose-specific loan transaction data from the purpose-specific loan source file 24 and generates the purpose-specific loan development data based on the transaction information data. And work to output.
  • FIG. 54 is a block diagram showing a configuration example of the purpose-specific loan transaction information developing means 5301.
  • the development means 5301 is connected to the purpose-specific loan ledger file 24.
  • Loan transaction information acquisition unit 5 4 0 1 continued by purpose and the transaction information acquisition unit 5
  • the components of the purpose-based loan development means 5310 are that the principal and cash flow processing unit 5404 generates development records for each change in the principal, interest, and deposit balances for each account. Except for, it operates in the same manner as the corresponding components of the card account transaction information expanding means 4201 shown in FIG.
  • the fixed / floating spread data distribution means 5302 has a function of dividing the loan development data for each purpose into spread data relating to fixed interest rates and spread data relating to floating interest rates.
  • the fixed-volume development data aggregation means 530 3 receives fixed-volume development data for fixed interest rates from the fixed-variation-based development data distribution means 5302, and based on the development data, fixes the development data for each purpose. It functions to generate aggregated loan data by purpose for fixed minutes that aggregates development data related to interest rates, and to output this.
  • FIG. 55 is a block diagram showing a configuration example of the mortgage transaction information expanding means 5306.
  • the developing means 5306 comprises a mortgage transaction information acquisition section 55001 connected to the mortgage ledger file 25, and a transaction information acquisition section.
  • the mortgage development means 5300 receives the mortgage transaction information data from the mortgage ledger file 25, and based on the transaction information data, Functions to generate and output loan development data.
  • the respective components of the mortgage transaction information developing means 530, except for the Cap processing unit 550, are the corresponding components of the purpose-specific loan transaction information developing means 5301, shown in FIG. It operates in the same way as.
  • variable development data aggregation means 5304 receives fixed development data related to floating interest rates from the fixed / floating development data distribution means 5320, and based on the development data, the floating interest rate of loan development data for each purpose.
  • the function is to generate aggregated loan data by purpose, which aggregates development data related to minutes, and output this.
  • Fixed / floating / C ap deployment data distribution means 5 3 0 7 divides housing opening development data into development data for fixed interest rates, development data for floating interest rates — development data for evenings and cap Output function.
  • the fixed-volume development data overnight aggregation means 530 8 is fixed, variable, and receives the development data related to fixed interest rates from the CAP-specific development data distribution means 5307, and based on the development data, develops mortgage data. It functions to generate and output aggregated fixed-mortgage loan data that aggregates development data related to fixed interest rates.
  • Floating data development data aggregation means 503 9 9 is fixed, floating, and development data by Cap.Receives development data on floating interest rates from evening distribution means 530 7 and develops mortgage loans based on the development data. Development related to floating interest rates in data The function is to generate and output aggregated mortgage data for floating rates that summarizes data.
  • C ap development data aggregation means 5 3 1 0 is fixed / floating ⁇
  • C ap development data distribution means 5 3 0 7 receives development data on C ap part from development data and develops mortgage based on the development data
  • the development data about the Cap It functions to generate aggregated data for Cap that summarizes the evening and passes it to the risk management system 3.
  • the fixed-part aggregated data merging means 5305 receives the fixed-rate expanded data from the fixed-part expanded data aggregation means 5330 and 5308, respectively, and converts them into one fixed-part aggregated data. Has the function of passing to the risk management system 3.
  • variable aggregated data merging means 5 3 1 1 receives the expanded data relating to the variable interest rate from the variable expanded data aggregate means 5 3 4 and 5 3 9, respectively, and combines them into one variable aggregated data. Has the function of passing to system 3.
  • Fig. 56 shows a scenario of a transaction example of loans by purpose and mortgages.
  • loan accounts # 1 to # 6 having the contents shown in Fig. 57 were opened on February 10, 2000, and thereafter, a predetermined amount of repayment was made for each account on each contract day every month. What happens.
  • the purpose-specific loan ledger file 24 includes records R5702, R5703, and R5705 corresponding to accounts # 2, # 3, and # 5.
  • the recorded loan transaction information developing means 5301 acquires the record, and generates expanded data relating to the fixed interest rate and the floating interest rate, respectively, from the record.
  • the generated expanded data is divided by the distributing means 5302 into expanded data relating to the fixed interest rate and expanded data relating to the variable interest rate.
  • Fig. 58 shows the fixed interest rate transferred from the distribution means 5302 to the fixed development data aggregation means 5330.
  • FIG. 59 is a diagram showing development data relating to the variable interest rate passed from the distribution means 5302 to the variable development data aggregation means 5304.
  • the fixed part expanded data aggregation means 5 3 0 3 and the variable part expanded data aggregation means 5 3 0 4 respectively group the records of the expanded data for each repayment date and for each repayment, and record the records in the same group.
  • the principal, interest, and loan balances are combined to generate aggregated data.
  • the mortgage ledger file 25 contains records R5701, R5704, R570 corresponding to accounts # 1, # 4, and # 6. 6 is recorded, and the mortgage transaction information expanding means 5330 acquires the record and generates expanded data relating to the fixed interest rate, the floating interest rate, and the Cap, respectively.
  • the generated development data is divided into fixed-development data for fixed interest rates, development data for floating interest rates, and expansion data for Cap, by the distribution means 530, respectively. It is passed to the aggregation means 5308, the fluctuation data development data aggregation means 5309, and the Cap development data aggregation means 5310.
  • FIG. 60 is a diagram showing expanded data relating to the fixed interest rate passed from the distribution means 530 7 to the fixed development data aggregation means 5308
  • FIG. 61 is a view showing the distribution means 530
  • FIG. 6 is a diagram showing expanded data relating to the variable interest rate passed from 7 to the variable development data aggregation means 5309
  • FIG. 6 2 shows the distribution data aggregation means 5 from the distribution means 5307.
  • FIG. 7 is a diagram showing an unfolding process regarding the Cap component passed to 310.
  • the fixed-volume development data overnight aggregation means 5330 and the variable-expansion data aggregation means 5309 each group the records of the development data for each repayment date and each payback, and Aggregate data is generated by adding the principal, interest, and loan balance of the record.
  • the Cap data expanded data aggregation means 5 3 10 10 groups the records of the expanded data into records having the same repayment and the same S trike, and sums up the balances of the records in the same group to aggregate the data. Produce evening.
  • Fig. 63 shows an example of the aggregated data generated by the Cap data expanded data aggregation means 5310.
  • the fixed-minute aggregated data merger 5305 receives the fixed-minute aggregated data from the fixed-value-developed data aggregaters 5303 and 5308, generates one fixed-minute aggregated data, and Pass to risk management system 3.
  • FIG. 64 shows the fixed-part aggregated data generated by the fixed-part aggregated data management means 5305 and passed to the risk management system 3.
  • variable aggregated data merging means 5 311 receives the variable aggregated data from the variable expanded data aggregation means 5 304 and 5309 and generates one fixed aggregated data. This is passed to the risk management system 3.
  • FIG. 65 shows an example of a variation aggregated data generated by the variation aggregate data merging means 5 3 11 and passed to the risk management system 3.

Description

明細書
金融取引に関する取引情報を集約する装置
技術分野
本発明は、 金融取引に関する取引情報を集約する装置、 その方法、 該 装置を実行するプログラムを格納した記録媒体、 該方法を実行するため のプログラムを記憶した記録媒体に関する。 より詳しくは、 金融取引に 関する取引情報を記憶した装置から取引情報を取得し、 該データに基づ いてキャッシュ · フローを示す展開データを生成し、 該展開デ一夕を所 定の集約条件に基づいて集約することにより、 キャッシュ · フローを正 確に表す集約されたデータをリスク管理システムに供給することを可能 とする技術に関する。 背景の技術
近年加速度的に進展しつつある金融の自由化、 国際化、 機械化は、 銀 行に対してビジネスチャンスの拡大という恩恵をもたらす一方で、 従来 では考えられなかったような、 いくつかの、 それもときには経営の看過 に重大な影響を及ぼすようなリスクを将来することとなった。 このよう な背景の元にリスク管理が、 銀行経営における重大なテーマとして意識 され、 当局をはじめとする関係各方面で盛んに議論されるようになって きたことは、 周知の通りである。
銀行経営を巡るリスクと言った場合、 様々の方面でいくつかの分類が なされているが、 金利リスク （金利変動に伴い、 利ざやや保有資産の価 値などが変動するリスク） 、 流動性リスク （資金の出入りのタイミン グ、 金額の不一致などにより、 資金繰りが破綻するリスク） 、 為替リス ク （為替相場の変動に伴い、 円貨ベースでの資金 ·負債価値が変動する リスク） が含まれることが一般に知られている。
かかるリスクを管理するために、 キャッシュ · フロー情報を解析し、 リスク量、 ヘッジ等の算出を行い経営判断の支援を行うリスク管理シス テムが、 多くの金融機関などに導入され利用されている。
リスク管理システムを利用するに際し、 為替市場における為替取引、 資金調達等にかかる市場取引等件数は少ないが取扱額の大きなキヤッシ ュ · フロー情報をリスク管理システムに供給し、 正確なリスク管理を行 うようにされていた。 しかし、 いわゆるリテール取引といわれる対顧客 系の取引、 たとえば預金の入出金、 利息の支払など件数は膨大であるが 個々の取扱量は小さなキャッシュ · フロー情報については、 担当者など の経験にもとづく大まかな数値をリスク管理システムに提供しているた めに、 これらの正確なリスク管理が行われているとは言い難い状態であ つた。 件数が非常に膨大であるために該システムのハ一ドウエア的処理 能力を超えてしまうおそれがあるためである。
本発明の目的は、 たとえば数十万単位の膨大な件数のキャッシュ · フ ロー情報を、 リスク管理システムにより処理可能なデータに集約するこ とを目的とする。 発明の開示
上記課題を解決する手段として、 本発明は以下のような特徴を有す る。
(請求の範囲第 1項）
請求の範囲第 1項に記載の発明は、 取引情報記憶装置から取引情報を 取得して、 該取引情報に基づいて金銭移動額の発生を表す展開レコード を生成し、 所定の集約条件に基づいて展開レコードをグループ化し、 同 一グループに属する複数の展開レコードから集約レコードを生成する。
ここで、 金銭移動額とは、 元金の入出金、 利息の支払、 融資残高の変 更などにかかる金額をい.う。
金銭の移動が発生する毎にその金額を格納した展開レコードが生成さ れるので、 正確な金銭の移動額 （キャッシュ ' フロー） が展開レコード に反映されている。 そしてかかる展開レコードを所定の集約条件で集約 レコードに集約することで、 リスク管理システムに渡すレコード件数、 ひいてはデ一夕量を減少させることが可能となる。
(請求の範囲第 2項）
請求の範囲第 2項に記載の発明は、 取引情報記憶装置に格納されてい る元帳ファイル毎に設けられた取引情報集約部を有し、 各取引情報集約 部は、 対応する元帳ファイルに格納されている金融商品の性質に応じて 前記所定の集約条件が定められていることを特徴とする。
一般に、 金融機関は様々な金融商品を取り扱い、 各金融商品毎に日々 キャッシュ · フローが発生するが、 キャッシュ · フローの発生する条 件、 内容は金融商品毎に異なっている。 本発明では、 各金融商品毎にそ の商品に適した集約部を設けることにより、 金融機関の扱う金融商品に ついてのリスクを一括して処理することを可能とする。
(請求の範囲第 3項）
請求の範囲第 3項にかかる発明は、 取引情報集約部が元金、 利息、 及 び残高の少なくとも一つの変動日及びその変動量を格納した展開レコー ドを生成する取引情報展開手段と、 該展開レコードを集約条件に基づい てグループ化し、 グループ化された展開レコードの元金、 利息、 及び残 高の少なくとも一つを合算することにより集約レコードを生成する取引 情報集約手段とを具備していることを特徴とする。
かかる発明において、 展開レコードは元金、 利息、 及び残高の少なく とも一つの変動日及びその変動量を格納しでいるので、 日単位で正確な キャッシュ · フロー量を把握することが可能となる。
また、 扱う金融商品の特性に応じた集約条件が用いられるので、 集約 後のデータも日単位で正確なキャッシュ · フロー量をリスク管理システ ムに渡すことが可能となる。
(請求の範囲第 6項）
請求の範囲第 6項にかかる発明は、 取引情報記憶装置から取引情報を 取得して、 該取引情報に基づいて元金、 利息、 融資残高の少なくとも一 つの変化を表す展開レコードを生成する展開レコード生成工程と、 所定 の集約条件に基づいて展開レコードをグループ化し、 同一グループに属 する複数の展開レコードから一の集約レコードを生成する集約レコード 生成工程とを具備することを特徴とする。
ここで、 金銭移動額とは、 元金の入出金、 利息の支払、 融資残高の変 更などにかかる金額をいう。
金銭の移動が発生する毎にその金額を格納した展開レコードが生成さ れるので、 正確な金銭の移動額 （キャッシュ · フロー） が展開レコード に反映されている。 そしてかかる展開レコードを所定の集約条件で集約 レコードに集約することで、 リスク管理システムに渡すレコード件数、 ひいてはデータ量を減少させることが可能となる。 図面の簡単な説明
第 1図は、 本発明にかかる取引情報集約装置を説明するためのブロッ ク図である。
第 2図は、 実施の形態にかかる取引情報集約装置の構成例を示すため のブロック図である。
第 3図は、 普通預金取引情報集約部の構成例を示すブロック図であ る。
第 4図は、 普通預金元帳ファイルのレコードの構成例を示す図であ る。
第 5図は、 普通預金に関する取引例のシナリォを示す図である。
第 6図は、 普通預金展開データを示す図である。
第 7図は、 普通預金集約データを示す図である。
第 8図は、 普通預金展開データを示す図である。
第 9図は、 普通預金集約データを示す図である。
第 1 0図は、 普通預金展開データを示す図である。
第 1 1図は、 普通預金集約データを示す図である。
第 1 2図は、 普通預金展開データを示す図である。
第 1 3図は、 普通預金集約データを示す図である。
第 1 4図は、 普通預金展開データを示す図である。
第 1 5図は、 普通預金集約データを示す図である。
第 1 6図は、 普通預金展開データを示す図である。
第 1 7図は、 普通預金集約データを示す図である。
第 1 8図は、 定期預金取引情報集約部の構成例を示す図である。
第 1 9図は、 定期展開手段および定期集約手段の構成例を示すブロッ ク図である。
第 2 0図は、 定期預金元帳ファイルのレコードの構成例を示す。
第 2 1図は、 期預金に関する取引例のシナリオを示す図であ 。
第 2 2図は、 定期預金展開データを示す図である。
第 2 3図は、 定期預金集約データを示す図である。 ' 第 2 4図は、 定期預金展開データを示す図である。 第 2 5図は、 定期預金集約データを示す図である。
第 2 6図は、 定期預金展開データを示す図である。
第 2 7図は、 定期預金集約データを示す図である。
第 2 8図は、 定期預金展開データを示す図である。
第 2 9図は、 定期預金集約データを示す図である。
第 3 0図は、 定期預金展開データを示す図である。
第 3 1図は、 定期預金集約データを示す図である。
第 3 2図は、 定期預金展開データを示す図である。
第 3 3図は、 定期預金集約データを示す図である。
第 3 4図は、 為替予約情報処理手段の構成例を示すブロック図であ る。
第 3 5図は、 定期預金に関する取引例のシナリオを示す図である。 第 3 6図は、 為替予約データ受取部が定期預金元帳ファイルから取得 したデ一夕の内容の一例を示す図である。
第 3 7図は、 買金額 ·売金額算出部において行われる計算を説明する ための図である。
第 3 8図は、 買金額 ·売金額算出部によって生成される為替予約情報 集約データの例を示す図である。
第 3 9図は、 買金額 ·売金額算出部によって生成される為替予約情報 集約デ一夕の例を示す図である。
第 4 0図は、 買金額 ·売金額算出部によって生成される為替予約情報 集約データの例を示す図である。
第 4 1図は、 買金額 ·売金額算出部によって生成される為替予約情報 集約データの例を示す図である。
第 4 2図は、 力一ドロ一ン取引情報集約部の構成例を示すブロック図 である。 第 4 3図は、 力一ドローンに関する取引例のシナリオを示す図であ る。
第 4 4図は、 カードロ一ン元帳ファイルに格納されている取引情報例 を示す概念図である。
第 4 5図は、 カードローン展開データの例を示す図である。
第 4 6図は、 カードローン集約データの例を示す図である。
第 4 7図は、 カードローン元帳ファイルに格納されている取引情報例 を示す概念図である。
第 4 8図は、 力一ドロ一ン展開データの例を示す図である。
第 4 9図は、 カードローン集約データの例を示す図である。
第 5 0図は、 カードロ一ン元帳ファイルに格納されている取引情報例 を示す概念図である。
第 5 1図は、 カードローン展開データの例を示す図である。
第 5 2図は、 カードローン集約デ一夕の例を示す図である。
第 5 3図は、 目的別ローン ·住宅ローン取引情報集約部の構成例を示 すブロック図である。
第 5 4図は、 目的別ローン取引情報展開手段の構成例を示すブロック 図である。
第 5 5図は、 住宅ローン取引情報展開手段の構成例を示すブロック図 である。
第 5 6図は、 目的別ローン ·住宅ローンに関する取引例のシナリォを 示す図である。
第 5 7図は、 第 5 6図に示すシナリォ 用いるローン口座の内容を示 す図である。
第 5 8図は、 固定金利分に関する展開データを示す図である。
第 5 9図は、 変動金利分に関する展開デ一夕を示す図である。 第 6 0図は、 固定金利分に関する展開デ一夕を示す図である。
第 6 1図は、 変動金利分に関する展開データを示す図である。
第 6 2図は、 C a p分に関する展開データを示す図である。
第 6 3図は、 C a p分展開データ集約手段により生成される集約デ一 夕の例を示す図である。
第 6 4図は、 固定分集約デ一夕マージ手段により生成されリスク管理 システムに渡される固定分集約データの例を示す図である。
第 6 5図は、 変動分集約データマージ手段により生成されリスク管理 システムに渡される変動分集約データの例を示す図である。 発明を実施するための最良の形態
以下に、 本発明の実施の形態を図面を参照しながら説明する。
第 1図は、 本発明にかかる取引情報集約装置を説明するためのプロッ ク図である。 取引情報集約装置 1は、 コンピュータ、 ワークステーショ ンなどの情報処理装置であって、 一般に勘定系システムに含まれる取引 情報ファイルを含む取引情報記憶装置 2から取引情報を取得可能に接続 されるとともに、 リスク管理システム 3に接続されており、 取引情報記 憶装置 2に記憶された取引情報を集約してリスク管理システム 3に提供 する。 なお、 取引情報集約装置 1を構成する情報処理装置は、 必ずしも 物理的に一つの装置である必要はなく、 各構成要素を一つの情報処理装 置により実現し、 これら構成要素の集合として本取引情報集約装置 1を 構成しても良い。
なお、 取引情報記憶装置 2は、 勘定系システムに含まれる取引情報フ アイルの複製であるファイルから構成されていてもよい。 より詳しく言 えば、 取引情報ファイルの内容を、 例えば 1 日の取引締め時においてパ ツチ処理あるいはオンライン処理により取引情報記憶装置 2内のフアイ ルに複製してもよい。 さらに、 取引情報記憶装置 2が取引情報ファイル の複製ファイルから構成された場合、 この複製ファイルは勘定系システ ムの取引情報ファイルに対してオンライン、 リアルタイムで接統されて いる必要はなく、 後述するリスク管理に必要な間隔、 例えば 1 日 1回バ ツチ処理等によりバックアップされればよい。 加えていえば、 この複製 ファイルは、 取引情報ファイルの全項目に対する複製である必要もな く、 後述するリスク管理に必要な項目のみ最低限複製されればよい。 なお、 本明細書中、 「取引情報」 とは、 金銭の取引に関する情報を言 うものとし、 たとえば、 銀行の扱う各種預金取引に関する情報、 各種口 —ン取引に関する情報を含む概念である。 また、 「取引情報ファイル」 とは、 取引情報を読み書き可能に蓄積したファイルを言い、 たとえば銀 行システムにおける普通預金元帳ファイル、 定期預金元帳ファイル、 各 種ローン元帳ファイルを含む概念である。
また 「リスク管理システム」 とは、 金利リスク、 流動性リスク、 為替 リスクを含む金融機関経営に関するリスクを管理するシステムをいい、 たとえば米国 Summi t I nc .の TSSummi tなどが巿場に提供されているリス ク管理システムの例である。 リスク管理システム 3は、 取引情報集約装 置 1から供給される集約された取引情報やその他の取引情報を情報処理 することにより、 各種金利の決定、 リスクの変化に対するシミュレ一シ ヨンの実行等のリスク管理情報を生成し、 これを表示装置 4や印字装置 5によって提供する。
取引情報集約装置 1は、 取引情報記憶装置 2に格納された取引情報に 基づいて、 リスク管理に用いるための取引情報を集約して、 これをリス ク管理システムに供給する機能を有する。 かかる機能を達成するために 取引情報記憶装置 2から取引情報を取得して、 該取引情報に基づいて、 集約基準日 （取引情報集約装置が集約を実行する日、 あるいは図示しな い入力装置から指定された日をいう） のキャッシュ ·ムーブメントおよ び集約基準日以降のキャッシュ · フローの発生を表す展開レコードを生 成し、 所定の条件に基づいてグループ化された複数の展開レコードから 一つの集約レコードを生成する機能を有する。 取引情報集約装置 1は、 一又は複数の展開レコードに含まれる情報を正確に集約レコードに格納 するように機能するので、 正確な情報をリスク管理システムに提供する とともに、 リスク管理システムが処理するレコード数、 すなわちデータ 量を減少させることが可能となる。
第 2図は、 本実施の形態にかかる取引情報集約装置 1の構成例を示す ためのブロック図である。 同図において、 取引情報記憶装置 2は、 異な る金融商品に関する複数の取引情報ファイルである普通預金元帳フアイ ル 2 1， 定期預金元帳ファイル 2 2、 カードローン元帳ファイル 2 3 , 目的別ローン元帳ファイル 2 4、 住宅ローン元帳ファイル 2 5を有して いる。
取引情報集約装置 1は、 普通預金取引情報集約部 2 6， 定期預金取引 情報集約部 2 7， カードローン取引情報集約部 2 8 , 目的別ローン '住 宅ローン取引情報集約部 2 9を有しており、 普通預金元帳ファイル 2 1 は普通預金取引情報集約部 2 6に、 定期預金元帳ファイル 2 2は定期預 金取引情報集約部 2 7に、 カード口一ン元帳ファイル 2 3はカードロー ン取引情報集約部 2 8に、 目的別口一ン元帳ファイル 2 4および住宅口 ーン元帳ファイル 2 5は目的別ローン ·住宅ローン取引情報集約部 2 9 に接続されている。 各取引情報集約部 2 6〜 2 9は対応する元帳フアイ ルが扱う金融商品に関する集約データをリスク管理システム 3に供給す る。
取引情報集約部が元帳ファイルごとに設けてあるのは、 金融商品ごと に、 キャッシュ · フローの発生の条件 '仕方等が異なっているので、 こ れに対応するためである。 各取引情報集約部は、 取引情報ファイルに格 納された取引情報に基づいて、 リスク管理に用いるための取引情報を集 約して、 これをリスク管理システム 3に供給する機能を有する点で共通 するが、 各金融商品に対応するように展開データの作成方法、 集約方法 等において異なる部分を有する。 以下、 それぞれ取引情報集約部ごとに その構成と動作について説明する。
( 1 . 普通預金取引情報集約部）
( 1 . 1 . 構成例）
第 3図は、 普通預金元帳ファイル 2 1に適用される普通預金取引情報 集約部 2 6の構成例を示すブロック図である。 図示のように、 普通預金 取引情報集約部 2 6は、 普通預金取引情報展開手段 3 0 1と、 普通預金 取引情報集約手段 3 0 2とを具備している。
普通預金取引情報展開手段 3 0 1は、 普通預金元帳ファイル 2 1に接 続された普通預金取引情報取得部 3 0 3と、 該普通預金取引情報取得部 3 0 3に接続されたキヤッシュ ·ムーブメント処理部 3 0 4および利息 キャッシュ · フロー処理部 3 0 6と、 該処理部 3 0 4及び 3 0 6に接続 された普通預金展開デ一夕蓄積部 3 0 5とを有している。
普通預金取引情報取得部 3 0 3は、 普通預金元帳ファイル 2 1から金 銭の移動を計算するために必要なデータを、 該ファイルを構成するひと つのレコードごとに取得する機能を有する。
第 4図は、 普通預金元帳ファイル 2 1のレコードの構成例を示す。 該 レコードは、 口座番号フィールド 4 0 1 , 顧客番号フィールド 4 0 2 , 氏名フィールド 4 0 3 , 共通管理コード群のフィールド 4 0 4， 通帳残 高フィールド 4 0 5 , 最終取引日フィールド 4 0 6 , チェインアドレス フィールド 4 0 7 , 取引コ一ドフィ一ルド 4 0 8， 金額フィールド 4 0 9， 取扱日フィールド 4 1 0、 摘要フィールド 4 1 1， チェインァドレ スフィ一ルド 4 1 2、 …を有している。 この構造において通帳残高フィ —ルド 4 0 5には該レコ一ドに対応する普通預金口座の残高が記録さ れ、 取引コードフィールド 4 0 8には、 当該普通預金口座についての入 金、 出金、 利息等の取引を区別するためのコードが記録される。 金額フ ィールド 4 0 9にはその取引の金額が格納され、 取扱日フィールドには その取引の行われた日付が格納される。 チェインアドレス 4 1 2には、 当該レコードの次の部分のァドレスが記憶されており、 取引が行われる ごとに取引コードフィールド 4 0 8からチェインァドレスフィールド 4 1 2が生成され、 次々に連鎖して一つのレコードを形成するようになつ ている。
普通預金取引情報取得部 3 0 3は、 金銭の移動を計算するために必要 なデータ、 たとえば通帳残高フィールド 4 0 5 , 最終取引日フィールド 4 0 6、 取引コードフィールド 4 0 8， 金額フィ一ルド 4 0 9， 取扱日 フィールド 4 1 0などに記憶されているデータを取得する。
次に、 キャッシュ ·ムーブメント処理部 3 0 4は、 普通預金取引情報 取得部 3 0 3が取得したデータに基づいて普通預金元帳ファイル 2 1の レコードごとに、 処理基準日に発生した元金及び利息の変動を記録した 展開レコードを生成する。
一方、 利息キャッシュ · フロー処理部 3 0 6は、 普通預金取引情報取 得部 3 0 3が取得したデータに基づいて普通預金元帳ファイル 2 1のレ コードごとに、 次回利盛日の利息を算出し、 これを展開レコードに格納 して普通預金展開データ蓄積部 3 0 5に渡す。
普通預金展開データ蓄積部 3 0 5は、 キャッシュ ·ムーブメント処理 部 3 0 4および利息キャッシュ · フロー処理部 3 0 6から供給される展 開レコードを蓄積して普通預金展開データとして蓄積する。 普通預金展 開データは、 普通預金取引情報展開手段 3 0 1が普通預金元帳ファイル 2 1のすベてのレコードについて処理を行った結果生成されたすベての 普通預金取引情報展開レコードを集合させてなるデータである。
普通預金取引情報集約手段 3 0 2は、 前記普通預金展開デ一夕蓄積部 3 0 5に接続された集約対象抽出部 3 0 7と、 集約対象抽出部 3 0 7に 接続された集約内容計算部 3 0 8と、 集約内容計算部 3 0 8に接続され た普通預金集約データ蓄積部 3 0 9とを有する。
普通預金展開データが完成すると、 集約対象抽出部 3 0 7によって普 通預金展開データ蓄積部 3 0 5から普通預金展開データのレコード群の 内、 集約できるもの同士をグループ化して抽出する。 普通預金取引情報 集約部 2 6において、 「集約」 は同一のキャッシュ · フロー発生日 （元 金 -利息の移動日、 利盛日） かつ同一の通貨 （円、 米ドル、 ユーロな ど） にかかる展開レコードを、 一の集約レコ一ドに集約するように、 1 つのグループに構成する。 グループ化する方法としては、 たとえば、 キ ャッシュ · フロ一発生日および通貨をキーにして展開レコードのソ一ト を行い、 キャッシュ ' フロー発生日および通貨が先のレコードと異なる 場合は、 別のグループとする等により実現する。
次に、 集約内容計算部 3 0 8は、 グループ化されたレコード群を集約 対象抽出部 3 0 7から受け取ると、 各グループの元金の移動、 利息の移 動、 および次回利盛日を合算して、 一の集約レコードに格納し、 該集約 レコードを普通預金集約データ蓄積部 3 0 9に送る。 グループとならな い展開レコードについては、 合算を行わずに一つの集約レコードを生成 し、 普通預金集約データ蓄積部 3 0 9に送る。
すべてのグループについて処理を行うと、 集約レコードの集合である 普通預金集約データが完成し、 普通預金集約データ蓄積部 3 0 9は、 完 成した普通預金集約デ一夕を蓄積し、 蓄積された普通預金集約データを リスク管理システム 3に供給するように機能する。 なお、 集約レコードのフォ一マットは、 リスク管理システム 3の仕様 に合致したフォーマツトであることが望ましいが、 普通預金集約データ をリスク管理システム 3の仕様に合致したフォーマツトに変換する図示 しないィンターフェイス手段を介してリスク管理システム 3に普通預金 集約デ一夕を供給するようにしてもよい。
( 1. 2. 動作例）
次に、 第 5図に示す普通預金に関する取引シナリオを用いて、 普通預 金取引情報集約部 2 6の動作例を説明する。
第 5図は、 普通預金に関する取引例のシナリオを示す図である。 該シ ナリオにおいて、 2 0 0 0年 3月 1 0日に新規口座 # 1が開設され、 1 0 0, 0 0 0円が入金され、 新規口座 # 2が開設され、 1 50， 00 0 円が入金され、 新規口座 # 3が開設され、 5， 0 0 0, 0 00円が入金 される。 これらの利率は年 0. 0 5 %である。 その後、 4月 1 7日に別 の新規口座 # 4が開設され、 8 0， 0 0 0円が入金され、 口座 # 3の資 金から 1 0， 0 00米ドルが購入され、 この 1 0， 0 0 0米ドルは外貨 普通預金として預金される。 このときの円一ドル交換レートは 1 0 9. 00円/ドルとする。 次に、 4月 2 8日に口座 # 2から 1 00, 0 0 0 円出金されるが、 翌 2 9日に出金が取り消される。 次に、 7月 1 5日に 口座 # 1が解約される。 次に、 8月 1 5日に利盛日が到来しすべての口 座に利息が入れられる。
第 6図は、 キャッシュ ·ム一ブメント処理部 3 04および利息キヤッ シュ · フロー処理部 3 0 6の処理の後普通預金展開データ蓄積部 3 0 5 に格納された 2 0 0 0年 3月 1 0日当日の普通預金展開データを示す図 であり、 第 7図は、 該普通預金展開デ一夕を集約して生成され、 普通預 金集約データ蓄積部 3 0 9に格納された同日の普通預金集約デ一夕を示 す図である。 この場合において普通預金展開データは複数の展開レコ一ド R 6 0 1 , R 6 0 2 , R 6 0 3、 R 6 0 4、 R 6 0 5、 R 6 0 6からなり、 各 レコードは口座番号フィールド 6 0 1、 通貨フィールド 6 0 2、 CF (キャッシュ · フロー） 発生日フィールド 6 0 3、 入金元金フィールド 6 0 4、 出金元金フィールド 6 0 5、 出金利息額フィールド 6 0 6、 残 高フィ一ルド 6 0 7、 利息積数フィールド 6 0 8、 利率フィールド 6 0 9を有している。
また、 第 7図に示す普通預金集約データは集約レコード R 7 0 1、 R 7 0 2からなり、 集約レコードは、 商品種類フィールド 7 0 1， 集約 I Dフィールド 7 0 2 , 通貨フィールド 7 0 3， 日付フィールド 7 0 4 , 元金移動額フィールド 7 0 5， 利息移動額フィールド 7 0 6、 残高フィ 一ルド 7 0 7を有している。 商品種類フィールドには対応する金融商品 を特定するコードが記入される。 集約 I Dは、 普通預金集約データを識 別するための識別子である。
第 6図に示される普通預金展開データは、 以下のように生成される。 まず、 口座 # 1から # 3に関するレコ一ドを記録した普通預金元帳ファ ィル 2 1から普通預金取引情報取得部 3 0 3がデータを取得すると、 キ ャッシュ · ムーブメント処理部 3 0 4は口座 # 1から # 3が新規開設さ れ 3月 1 0日にそれぞれ入金があったことを、 前述の取引コードフィー ルド 4 0 8、 金額フィールド 4 0 9、 取引日フィールド 4 1 0 (第 4図 参照） から判断し、 展開レコード R 6 0 1 , R 6 0 2 , R 6 0 3を生成 する。
展開レコードの口座番号、 通貨、 C F発生日、 利率のフィールドに は、 普通預金取引情報取得部 3 0 3から取得したデータが格納される。 各口座の入金額は対応するレコードの入金元金フィールド 6 0 4、 残 高フィールド 6 0 7に格納される。 普通預金取引情報取得部 3 0 3は出金利息額 6 0 6， 利息積数 6 0 8 に入力が必要かどうかを判断するが、 いずれもこの場合には不要である ので入力せずに展開レコード R 6 0 1， R 6 0 2 , R 6 0 3を生成す る。
一方、 利息キャッシュ ' フロー処理部 3 0 6は、 該口座が 3月 1 0に 新規開設されたことを普通預金取引情報取得部 3 0 3のデータから判断 し、 預入期間が 0日のため利息 0円の展開レコード R 6 0 4， R 6 0
5 , R 6 0 6の生成を行う。
これにより普通預金展開データ蓄積部 3 0 5は、 第 6図に示すような 普通預金展開データを蓄積する。 なお、 展開レコードのフィールドに記 入される金額である元金移動額等について、 銀行から見て入ってくるも のを 「十」 （正） 、 銀行から見て出ていくものを 「一」 （負） と定義す るものとする。
次に、 普通預金取引情報展開手段 3 0 1が普通預金取引情報集約手段 3 0 2に処理を開始するよう指示する。 指示を受けた普通取引情報集約 手段 3 0 2は、 集約対象抽出部 3 0 7が、 普通預金展開データ蓄積部 3 0 5から普通預金展開データを取得し、 該普通預金展開データを構成す る複数の展開レコードの内集約できるもの同士をグループ化して抽出す る。
この例の場合、 グループ化の条件 （集約条件） は同一 C F発生日かつ 同一通貨展開のレコードであることであり、 かかる集約条件を満たすレ コード同士をグループ化する。 この例の場合展開レコード R 6 0 1， R
6 0 2， R 6 0 3及び R 6 0 4， R 6 0 5 , R 6 0 6はそれぞれ同一通 貨かつ同一 C F発生日なので、 これら展開レコードの組 R 6 0 1〜R 6 0 3及び R 6 0 4〜R 6 0 6がーつのグループを構成する。 集約内容計 算部 3 0 8は、 例えば R 6 0 1〜R 6 0 3を一のグループとして受け取 り、 3つの展開レコ一ド R 6 0 1〜R 6 0 3の入金元金フィールド 6 0 4、 出金元金フィールド 6 0 5のデ一タを合算して、 集約レコードの元 金移動額フィールド 7 0 5のデータを生成し、 出金利息額 6 0 6フィ一 ルドのデ一夕を合算して利息移動額 7 0 6のデ一夕を生成し、 残高フィ ールド 6 0 7のデ一夕を合算して残高フィールド 7 0 7のデ一タを生成 し、 また商品種類、 集約 I Dを図示しない変換テーブルを参照して対象 金融商品、 通貨に応じたコードを作成してこれを格納することにより、 集約レコード R 7 0 1を生成する。 同様に； 6 0 4 , R 6 0 5 , R 6 0 6を一つのグループとし、 これを上記のように集約することにより集約 レコード R 7 0 2を生成する。
該集約レコード R 7 0 1、 R 7 0 2は普通預金集約データ蓄積部 3 0 9に蓄積され、 必要に応じてリスク管理システム 3に供給される。
次に、 4月 1 7日における動作について説明する。 第 8図は、 4月 1 7日を処理基準日とする普通預金展開データを示す図であり、 第 9図 は、 同日の普通預金集約データを示す図である。
取引情報展開手段 3 0 1は、 第 6図， 第 7図に関して述べたところの 動作と同様にして、 第 8図に示す普通預金展開デ一夕を生成する。
普通預金展開データは、 キャッシュ ·ムーブメント処理部 3 0 4によ つて生成された、 処理基準日の元金及び利息の移動と預金残高に関する 展開レコードである口座 # 1に関する展開レコード R 8 0 1と、 口座 # 2に関する展開レコード R 8 0 2と、 口座 # 3に関する展開レコード R 8 0 3、 R 8 0 4と、 口座 # 4に関する展開レコード R 8 0 5を含んで いる。 なお、 キャッシュ ·ムーブメント処理部 3 0 4はこれら展開レコ —ドの C F発生日フィールド 8 0 3に、 処理基準日 2 0 0 0年 4月 1 7 日を表す 「 2 0 0 0 0 4 1 7」 を記入する。
4月 1 7日では、 新規口座 # 4が開設され、 8 0 , 0 0 0円が入金さ れ、 口座 # 3の資金から 1 0, 0 0 0米ドルが購入され、 この 1 0， 0 00米ドルは外貨普通預金として預金される。 これらについては、 普通 預金取引情報展開手段 30 1が展開レコ一ドを以下のように生成するこ とにより正確な取引情報を展開レコードに反映させている。 まず、 新規 口座 # 4開設については、 展開レコード R 8 0 5が生成されており、 そ の次回利盛日 （ 8月 1 5日） 利息を表す展開レコード R 8 10も生成さ れる。 また、 口座 # 3の資金から 1 0， 0 0 0米ドルの購入は、 展開レ コード R 8 0 3における出金元金フィ一ルドの 「 1 0 9 0 000」 によ つて表されている。 また、 1 0, 0 0 0米ドルの外貨普通預金は、 展開 レコード R 8 04によって表されている。 レコード R 8 04には通貨が 米ドルであることを示すコード 「USD」 が通貨フィールド 80 2に記 入されている。
さらに、 利息キャッシュ ， フロー処理部 3 0 6は、 次回利盛日利息に 関する展開レコードである口座 # 1に関する展開レコード R 806と、 口座 # 2に関する展開レコード R 80 7と、 口座 # 3に関する展開レコ ード R 8 0 8、 R 8 0 9と、 口座 # 4に関する展開レコード R 8 1 0を 生成する。 これら展開レコード R 8 0 6〜R 8 1 0の出金利息額フィ一 ルドには、 次回利盛日利息がそれぞれ格納される。 なお、 次回利盛日利 '息は、 処理基準日の預金残高に対して前回利盛日 （最初の利盛日が到来 していない場合は口座開設日） より処理基準日までの利息に相当する。 また、 利息キャッシュ · フロー処理部 306は、 これらレコードの C F 発生日フィールドに次回利盛日 2 0 0 0年 8月 1 5日を表す 「 20 0 0 0 8 1 5」 を記入する。
このようにして、 処理基準日 （4月 1 7日） 時点でのすべての口座に ついて、 元金及び利息の移動と預金残高、 および次回利盛日 （8月 1 5 日） での利息を展開レコードによって表している。 次に、 取引情報集約手段 3 0 2は、 先に述べたと同様にして同一通貨 かつ同一 C F発生日の展開レコードをグループ化し、 グループ化された 展開レコードを一つの集約レコードに集約する。 すなわち、 通貨が円 ( J P Y ) 、 キャッシュ · フロー発生日が 4月 1 7日を示す普通預金展 開データ R 8 0 1 , R 8 0 2 , R 8 0 3 , R 8 0 5が集約対象抽出部に よって第 1のグループとしてグループ化されて抽出され、 集約内容計算 部 3 0 8によって集約レコ一ド R 9 0 Γに集約される。
また、 通貨 「ドル」 について 4月 1 Ί日のキャッシュ · フローを示す 普通預金展開データ R 8 0 4が集約対象抽出部 3 0 7によって第 2のグ ループとして抽出され、 集約内容計算部 3 0 8によって集約レコード R 9 0 2に集約される。
また、 通貨 「円」 について 8月 1 5日のキャッシュ ' フローを示す普 通預金展開デ一夕 R 8 0 6， R 8 0 7 , R 8 0 8 , R 8 1 0が集約対象 抽出部 3 0 7によって第 3のグループとしてグループ化されて抽出さ れ、 集約内容計算部 3 0 8によって集約レコード R 9 0 3に集約され る。
そして、 通貨 「ドル」 について 8月 1 5日のキャッシュ ' フローを示 す普通預金展開データ R 8 0 9が集約対象抽出部 3 0 7によって抽出さ れ、 集約内容計算部 3 0 8によって集約レコード R 9 0 4に集約され る。
次に、 処理基準日が 4月 2 8日における動作について説明する。 第 1 0図は、 処理基準日が 4月 2 8日の場合に普通預金取引情報展開手段 3 0 1によって生成される普通預金展開データを示す図であり、 第 1 1図 は、 該普通預金展開データから普通預金取引情報集約手段 3 0 2が生成 する普通預金集約データを示す図である。
第 5図のシナリオに示すように、 4月 2 8日に口座 # 2から 1 0 0， 00 0円出金されるので、 普通預金元帳ファイル 2 1から普通預金取引 情報取得部 3 0 3が取得したデータに基づいて、 キャッシュ 'ム一ブメ ント処理部 3 0 ,4は当該元金の移動が生じたことを判断して、 その出金 元金フィールドに出金金額を格納した展開レコ一ド R 1 0 02を生成す る。 また、 他の口座 # 1 , # 3， # 4については 4月 2 8日時点の残高 を格納した展開レコード R 1 0 0 1 , R 1 00 3 , R 1 0 04, R 1 0 0 5を生成する。
また、 利息キャッシュ · フロー処理部 3 06は、 各口座 # 1〜# 4に ついての次回利盛日 （8月 1 5日） の利息の算出を行い、 該計算した利 息を格納した展開レコード R 1 00 6〜R 1 0 1 0を生成する。
上記生成された展開レコード R 1 0 0 1〜R 1 0 1 0は普通預金展開 データ蓄積部 3 0 5に普通預金展開データとして格納される。
第 1 1図に示す普通預金集約データの生成は、 前述と同様に、 前記普 通預金展開データ蓄積部 3 0 5に格納された普通預金展開データに基づ いて集約対象抽出部 30 7によるグループ化および集約内容計算部 30 8による集約レコード生成によって前述と同様に行われる。 なお、 集約 レコード R l 1 0 1の元金移動額フィールドに、 口座 # 2からの 1 0 0, 0 0 0円の出金というキャッシュ · フローが反映されている。
次に、 4月 2 9日における動作について説明する。 第 1 2図は、 処理 基準日を 4月 2 9日とした場合に普通預金取引情報展開手段 3 0 1によ つて生成される普通預金展開データを示す図であり、 第 1 3図は、 その 普通預金展開データから普通預金取引情報集約手段 3 0 2によって生成 される普通預金集約データを示す図である。
第 5図のシナリオに示すように、 4月 2 9日に口座 # 2から 1 0 0, 00 0円の出金が取り消されている （たとえば、 支店端末の誤動作によ り誤った出金情報が 4月 2 8日に発生した際の訂正など） ので、 普通預 金元帳ファイル 2 1から普通預金取引情報取得部 30 3がデータを取得 すると、 キヤッシュ ·ムーブメント処理部 3 04は当該元金の移動が生 じたと判断して、 その出金元金フィールドに当該金額を格納する展開レ コード R 1 2 Q 2を生成する。 なお、 取消なので 「マイナス」 の符号が 付与される。 '
また、 他の口座 # 1, # 3， # 4については 4月 2 8日時点の残高を 格納した展開レコード R 1 20 1， R 1 2 0 3 , R 1 2 04, R 1 2 0 5を生成する。
また、 利息キャッシュ ' フロー処理部は、 各口座 # 1〜# 4について の次回利盛日 （8月 1 5日） 利息の算出を行い、 該計算した利息を格納 した展開レコード R 1 2 0 6〜R 1 2 1 0を生成する。
第 1 3図に示す普通預金集約データの生成は、 前述と同様に、 前記普 通預金展開データ蓄積部 3 05に格納された普通預金展開データに基づ いて集約対象抽出部 30 7によるグループ化および集約内容計算部 3 0 8による集約レコード生成によって前述と同様に行われ、 集約レコード R 1 3 0 1から R 1 304が生成される。 なお、 集約レコード R.1 3 0 1の元金移動額フィ一ルド及び残高に、 口座 # 2からの 1 0 0， 0 0 0 円の出金取消というキャッシュ · フローが反映されている。
次に、 処理基準日が 7月 1 5日における動作について説明する。 第 1 4図は、 処理基準日が 7月 1 5日とされた場合に生成される普通預金展 開データを示す図であり、 第 1 5図は、 該普通預金展開データから普通 預金取引情報集約手段 3 02が生成する普通預金集約データを示す図で ある。
第 5図のシナリオに示すように、 7月 1 5日に口座 # 1が解約されて いるので、 普通預金元帳ファイル 2 1から普通預金取引情報取得部 3 0 3が取得したデータに基づいて、 キャッシュ ·ムーブメント処理部 3 0 4は口座 # 1について解約により残高 1 0 0、 0 0 0円およびその解約 日までに生じた利息が出金され、 残高が 0円になったという元金及び利 息の移動、 残高の変動が生じたことを判断して、 その出金元金フィ一ル ド、 出金利息額フィールド、 及び残高フィールドに対応する金額が格納 された展開レコ ド R 140 1を生成する。
また、 他の口座 # 2, # 3， # 4については 7月 1 5日時点の残高を残 高フィールドに格納した展開レコード R 1 40 2 , R 1403 , R 14 04， R 140 5を生成する。
また、 利息キャッシュ · フロー処理部 3 0 6は、 解約された口座 # 1 を除いた口座 # 2〜# 4についての次回利盛日 （8月 1 5日） 利息の算 出を行い、 該計算した利息を出金利息額フィールドに格納した展開レコ —ド R 140 6〜R 140 9を生成する。 口座 # 1は解約されたので、 利息キャッシュ · フロー処理部 30 6はキャッシュ · フロー （利息支 払） の普通預金展開データを口座 # 1については生成しない。
以上のようにして生成され'た展開レコード R 1 40 1〜R 140 9は 普通預金展開データ蓄積部 30 5に普通預金展開データとして格納され る。
第 1 5図に示す普通預金集約データの生成は、 前述と同様に、 前記普 通預金展開データ蓄積部 3 0 5に格納された普通預金展開データに基づ いて集約対象抽出部 3 0 7によるグループ化および集約内容計算部 3 0 8による集約レコード生成によって前述と同様に行われる。 なお、 集約 レコード R 1 5 0 1の元金移動額フィールドに口座 # 1からの 1 0 0, 000円の元金支払及び利息支払というキャッシュ · フローが反映され ている。
次に、 8月 1 5日における動作について説明する。 第 16図は、 処理 基準日を 8月 1 5日とした場合に普通預金取引情報展開手段 30 1によ つて生成される普通預金展開デ一タを示す図であり、 第 1 7図は、 その 普通預金展開データから普通預金取引情報集約手段 3 0 2によって生成 される普通預金集約デ一夕を示す図である。
第 5図のシナリオに示すように、 8月 1 5日はすべての普通預金口座 に対して利息が確定し支払われる利盛日である。 普通預金元帳ファイル 2 1から普通預金取引情報取得部 3 0 3がデータを取得すると、 キヤッ シュ ·ムーブメント処理部 3 0 4は当該キャッシュ · フロー （利息支払 い ，確定） が生じたことを判断して、 出金利息額フィールドに支払われ る利息額を格納した展開レコード R 1 6 0 1 , R 1 6 0 2 , R 1 6 0 3， R 1 6 0 4を生成する。
利息キャッシュ · フロー処理部 3 0 6は、 その出金利息額フィールド に利息金額を格納した次回利盛日である 2 0 0 1年 2月 1 5日に対応し た展開レコード R 1 6 0 5、 R 1 6 0 6、 R 1 6 0 7、 R 1 6 0 8を口 座 # 2から # 4について生成する。
第 1 7図に示す普通預金集約データの生成は、 前記普通預金展開デー 夕蓄積部 3 0 5に格納された普通預金展開データに基づいて集約対象抽 出部 3 0 7によるグループ化および集約内容計算部 3 0 8による集約レ コード生成によって前述と同様に行われる。 なお、 利息を残高に組み込 んだ額が集約レコードの残高フィールドに格納されるように集約内容計 算部 3 0 8が処理を行う。 そして上記生成された展開レコード R 1 7 0 1〜R 1 7 0 4は普通預金集約データ蓄積部 3 0 9に普通預金集約デー 夕として格納される。
以上のようにして、 処理基準日および将来生ずるキャッシュ · フロー を正確に表した普通預金集約データが生成され、 該普通預金集約デ一夕 は、 もととなる取引情報より大幅に件数 ·デ一タ量が減少している。 か かる普通預金集約データを用いることにより、 いわゆるリテール取引な どの非常に多件数になるキャッシュ · フローについても、 リスク管理シ ステムにより、 処理することが可能となる。
( 2 . 定期預金取引情報集約部）
( 2 . 1 . 構成例）
定期預金元帳ファイル 2 2に記録されている取引情報を集約する定期 預金取引情報集約部 2 7の構成例について第 1 8図を参照して説明す る。
同図に示すように、 定期預金取引情報集約部 2 7は、 定期預金取引情 報展開手段 （以下、 「定期展開手段」 と略す） 1 8 0 1と、 定期預金取 引情報集約手段 （以下、 「定期集約手段」 と略す） 1 8 0 2と、 外貨定 期預金為替予約情報処理手段 （以下、 「予約処理手段」 と略す） 1 8 0 3とを具備する。
定期展開手段 1 8 0 1は、 定期預金元帳ファイル 2 2から定期預金取 引情報データを受け取り、 該取引情報データに基づいて定期預金展開デ —夕を生成し、 出力するように機能する。 定期集約手段 1 8 0 2は定期 展開手段 1 8 0 1から定期預金展開データを受け取り、 該展開データに 基づいて定期預金集約データを生成し、 これをリスク管理システム 3に 出力するように機能する。 また、 予約処理手段 1 8 0 3は、 定期預金元 帳ファイル 2 2から外貨預金解約に係る為替予約データを受け取り、 該 為替予約データに基づいて為替予約情報集約データを生成し、 これをリ スク管理システム 3に出力するように機能する。
ここにいう為替予約とは、 ある外貨預金の満期日前において、 一定の 外貨額についてある特定の日の通貨交換レー卜で満期日の両替実行を予 約することをいう。 なお、.元帳ファイルが外貨預金を含まない場合は、 予約処理手段を設けなくともよい。
( 2 . 2 . 定期展開手段および定期集約手段の構成例） 第 1 9図は、 定期展開手段 1 8 0 1および定期集約手段 1 8 0 2の構 成例を示すブロック図である。 定期展開手段 1 8 0 1は、 定期預金元帳 ファイル 2 2に接続された定期預金取引情報取得部 1 9 0 1と、 該取引 情報取得部 1 9 0 1に接続されたキャッシュ ·ムーブメント処理部 1 9 0 2および元金等キャッシュ · フロー処理部 1 9 0 3と、 該処理部 1 9 0 2及び 1 9 0 3に接続された展開データ蓄積部 1 9 0 4とを有してい る。
取引情報取得部 1 9 0 1は、 定期預金元帳ファイル 2 2から金銭の移 動を計算するために必要なデータを、 該ファイルを構成するひとつのレ コードごとに取得する。 第 2 0図に定期預金元帳ファイル 2 2のレコー ドの構成例を示す。 第 4図に示す普通預金取引元帳ファイル 2 1のレコ 一ドと略同様なフィールドを有するとともに、 該レコードには定期預金 の期間を示す期間コードフィールド 2 0 0 1， 自動解約、 自動解約等の 種別を示す種別コードフィールド 2 0 0 2を含んでいるので、 これらを 参照することにより、 入出金処理部 3 2が、 定期預金の満期、 その自動 継続、 自動解約など定期預金特有の要素を処理できる。 取引情報取得部 1 9 0 1は、 レコードごとに必要なデータを読み出し、 キャッシュ ·ム ーブメント処理部 1 9 0 2および元金等キャッシュ · フロー処理部 1 9 0 3に渡す機能を有する。
キャッシュ · ムーブメント処理部 1 9 0 2は、 定期預金元帳ファイル 2 2のレコードごとに取引情報取得部 1 9 0 1が取得したデータに基づ いて処理基準日に発生した元金及び利息の変動を記録した定期預金展開 レコードを生成する。
一方、 元金等キャッシュ · フロー処理部 1 9 0 3は、 取引情報取得部 1 9 0 1が取得したデ一夕に基づいて定期預金元帳ファイル 2 2のレコ ードごとに、 元金 ·利息金額の変動日 （満期、 利払い日） における元 金 ·利息金額及び預金残高を計算し、 これを展開レコードに格納して定 期預金展開データ蓄積部 1 9 0 4に渡す機能を有する。
定期預金展開デ一タ蓄積部 1 9 0 4は、 キャッシュ · ムーブメント処 理部 1 9 0 2および元金等キャッシュ · フロー処理部 1 9 0 3から供給 されるレコードを蓄積して定期預金展開データを形成する。 定期預金取 引情報展開手段 1 8 0 1が定期預金元帳ファイル 2 2のすベてのレコー ドについて処理を行うと、 定期預金展開データが完成する。
定期預金取引情報集約手段 1 8 0 2は、 前記定期預金展開データ蓄積 部 1 9 0 4に接続された集約対象抽出部 1 9 0 5と、 集約対象抽出部 1 9 0 5に接続された集約内容計算部 1 9 0 6と、 集約内容計算部 1 9 0 6に接続された定期預金預金集約データ蓄積部 1 9 0 7とを有する。 集約対象抽出部 1 9 0 5は、 定期預金展開データ蓄積部 1 9 0 4から 定期預金展開データのレコード群の内、 集約できるもの同士をグループ 化して抽出する機能を有する。 集約は同一のキャッシュ · フロー発生日 (元金 ·利息の変動日、 新規口座開設日、 満期日、 利払日を含む） かつ 同一の通貨 （円、 米ドル、 ュ一口など） にかかる展開レコードを、 一の 集約レコードに集約するように機能する。 なお、 グループ化する方法と しては、 たとえばキャッシュ · フロー発生日および通貨をキ一にして展 開レコードのソートを行い、 キャッシュ · フロー発生日および通貨が先 のレコードと異なる場合は、 別のグループとする等により実現する。 次に、 集約内容計算部 1 9 0 6は、 グループ化されたレコード群を集 約対象抽出部 1 9 0 5から受け取ると、 各グループの元金、 利息、 預金 残高を合算して、 一の集約レコードに格納し、 該集約レコードを定期預 金集約データ蓄積部 1 9 0 7に送るように機能する。 グループとならな い展開レコードについては、 合算を行わずに一つの集約レコードを生成 し、 定期預金集約データ蓄積部 1 9 0 7に送るように機能する。 すべてのグループについて処理がおこなわれ、 集約レコードの集合で ある定期預金集約デ一夕が完成し、 定期預金集約データ蓄積部 1 9 0 7 は、 かかる完成した定期預金集約データを蓄積し、 リスク管理システム 3に供給するように機能する。
なお、 集約レコードのフォーマットは、 リスク管理システム 3の仕様 に合致したフォ一マツトであることが望ましいが、 定期預金集約データ をリスク管理システム 3の仕様に合致したフォーマツ3トに変換する図示 しないィンタ一フェイス手段を介してリスク管理システム 3に定期預金 集約データを供給するようにしてもよい。
(2. 3. 定期預金取引情報展開手段および定期預金取引情報集約手 段の動作例）
次に、 第 2 1図に示す定期預金に関する取引例を用いて、 定期預金取 引情報展開手段 1 8 0 1および定期預金取引情報集約手段 1 8 0 2の動 作例を説明する。 第 2 1図は、 定期預金に関する取引例のシナリオを示 す図である。
該シナリオにおいて、 2 00 0年 3月 1 0日に新規定期預金口座が 3 件開設される。 口座 # 1は、 預入額 1 , 0 0 0, 000円、 6ヶ月定期 預金で適用利率 0. 1 2 %、 元利自動継続型というものであり、 口座 # 2は、 預入額 3, 0 0 0, 00 0円、 2年定期預金で、 適用利率 0. 1 5 %、 利払式、 自動解約型というものである。 口座 # 3は、 預入額 2， ' 0 0 0， 0 00円、 3ヶ月定期預金で適用利率 0. 1 2 %、 元金自動継 続型というものである。 次に、 4月 1 7日に新規定期預金口座が 1件開 設される。 新規口座 # 4は、 預入額 5， 0 00, 000円、 2年定期預 金、 適用利率 0. 1 5 %、 自動解約型というものである。
次に、 6月 1 0日において口座 # 3は、 満期となり利払および元金自 動継続が行われる。 また、 新規口座が 2件開設され、 口座 # 5は、 預入 額 1 , 0 0 0, 0 0 0円、 3月定期預金、 適用利率 0. 1 2 %、 自動解 約型というものである。 またもう一つの新規口座口座 # 6は、 外貨定期 であって、 預入額 1 00, 00 0米ドル、 3ヶ月外貨定期預金、 適用利 率 4.45860%、 自動解約型というものである。
次に、 9月 1 0日において、 口座 # 1は、 満期となり該口座は元利自 動継続し、 口座 # 3も満期となり、 解約され、 口座 # 5も満期となり、 該口座は解約され、 口座 # 6も満期となり、 解約される。
次に、 2 0 0 1年 3月 1 0日において、 口座 # 1は満期となり解約さ れ、 口座 # 2について利払が行われる。
次に、 2 0 0 2年 3月 1 0日に口座 # 2が満期解約となり、 同年 4月 1 7日に口座 # 4が満期解約となる。
第 22図は、 20 00年 3月 1 0日において定期預金取引情報展開手 段 1 8 0 1によって生成される定期展開データを示す図であり、 第 2 3 図は、 同日において定期預金取引情報集約手段 1 802によって生成さ れる定期預金集約データを示す図である。
第 22図に示す定期預金展開データは複数の展開レコード R 220 1 〜R 2 2 0 7からなり、 各レコードは口座番号フィールド 220 1、 通 貨フィールド 2 2 0 2、 CF (キャッシュ ' フロー） 発生日フィールド 2 2 0 3、 入金元金フィールド 2 204、 出金元金フィールド 2 20 5、 出金利息額フィールド 22 0 6、 残高フィールド 2 207、 元加組 込利息フィールド 2 208、 利率フィールド 2 2 0 9を有している。
また、 第 23図に示す定期預金集約データは集約レコード R 2 3 0 1 〜R 2 3 0 5からなり、 各集約レコードは、 商品種類フィールド 2 3 0 1， 集約 I Dフィ一ルド 2 30 2 , 通貨フィールド 2 3 03, 日付フィ —ルド 2 3 04， 元金移動額フィールド 2 3 0 5, 利息移動額フィール ド 2 3 0 6、 残高フィールド 2 3 07を有している。 商品種類フィール ドには対応する金融商品を特定するコードが記入される。 集約 I Dは、 集約データを識別するための識別子である。
第 2 2図に示される展開デ一夕は、 以下のように生成される。 まず、 元帳ファイル 2 2から定期預金取引情報取得部 1 9 0 1がデータを取得 すると、 キャッシュ ·ムーブメント処理部 1 9 0 2は口座 # 1から # 3 が新規開設され、 3月 1 0にそれぞれ入金があったことを、 元帳フアイ ル 2 2の各口座に対応するレコードから判断し、 展開レコード R 2 2 0 1， R 2 2 0 2 , R 2 2 0 3を生成する。 口座番号フィールド 2 2 0 1、 通貨フィールド 2 2 0 2、 C F発生日フィールド 2 2 0 3、 利率フ ィ一ルド 2 2 0 9には、 元帳ファイルから取得したデータが格納され、 各口座の預入額は対応するレコードの入金元金フィールド 2 2 0 4、 残 高フィ一ルド 2 2 0 7に格納される。
また、 元金等キヤッシュ · フロー処理部 1 9 0 3は口座 # 1から # 3 の元金 ·利息の変動日として、 各口座の満期日の解約および利息の支払 いを表す展開レコード R 2 2 0 4〜R 2 2 0 7を生成する。 これら展開 レコードについて、 元金等キャッシュ · フロ一処理部 1 9 0 3は解約に よって支払われる元金、 及び解約時に支払われる利息、 利払い日に支払 われる利息を算出し、 それぞれ出金元金フィールド 2 2 0 5 , 出金利息 額フィ一ルド 2 2 0 6 , 残高フィ一ルド 2 2 0 7に算出した値を格納す る。
各展開レコードは展開データ蓄積部 1 9 0 4に渡される。 これらによ り展開データ蓄積部 1 9 0 4は、 第 2 2図に示すような展開デ一タを蓄 積することになる。
次に、 定期展開手段 1 8 0 1は定期集約手段 1 8 0 2に処理を開始す るよう指示する。 指示を受けた定期集約手段 1 8 0 2は、 集約対象抽出 部 1 9 0 5によって展開データ蓄積部 1 9 0 4から前記展開データを取 得し、 該展開データに含まれるレコード群の内集約できるもの同士をグ ループ化して抽出する。 この場合、 同一通貨かつ同一 C F発生日の展開 レコ一ドをグループ化する。 この例の場合展開レコード R 2 2 0 1 , R 2 2 0 2 , R 2 2 0 3は同一通貨かつ同一 C F発生日なので、 これら 3 つのレコードが一つの集約レコ一ドを構成する。
集約内容計算部 1 9 0 6は、 これら 3つのレコードを一のグループと して受け取り、 入金元金フィールド 2 2 0 4、 出金元金フィールド 2 2 0 5のデータを合算して、 元金移動額フィ一ルド 2 3 0 5のデータを生 成し、 出金利息額 2 2 0 6フィールドのデータを合算して利息移動額 2 3 0 6のデータを生成し、 残高フィールド 2 2 0 7のデータを合算して 残高フィールド 2 3 0 7のデータを生成し、 また商品種類、 集約 I Dを 図示しない変換テーブルを参照して対象金融商品、 通貨に応じたコード を作成してこれを格納することにより、 展開レコード R 2 3 0 1を生成 する。
また、 その他の展開レコード R 2 2 0 4 , R 2 2 0 5 , R 2 2 0 6 , R 2 2 0 7は他に同一通貨かつ同一 C F発生日の展開レコードが無いの で、 集約対象抽出部 1 9 0 5はそれぞれについて 1グループとして集約 内容計算部 1 9 0 6に渡し、 集約内容計算部 1 9 0 6はこれらに基づい て集約レコード R 2 3 0 2， R 2 3 0 3 , R 2 3 0 4 , R 2 3 0 5を生 成する。
これら集約レコード R 2 3 0 1〜R 2 3 0 5は集約データとして集約 デ一夕蓄積部 1 9 0 7に蓄積され、 必要に応じてリスク管理システム 3 に供給される。 なお、 集約レコードのフォーマットは、 リスク管理シス テム 3の仕様に合致したフォ一マツトであることが望ましいが、 集約デ 一夕をリスク管理システム 3の仕様に合致したフォ一マツトに変換する 図示しないィンターフェイス手段を介してリスク管理システム 3に集約 データを供給するようにしてもよい。
以降、 第 2 1図に示される同年 4月 1 7日から 2.00 2年 4月 1 7日 までの事象についても、 同様に、 新規加入、 利払い、 解約、 満期に応じ て定期預金取引情報展開手段 1 8 0 1によって定期預金展開データが生 成され、 該定期預金展開データに基づいて定期預金取引情報集約手段 1 80 2によって定期預金集約データが生成される。
それぞれの処理基準日で生成される定期預金展開データと定期預金集 約デ一夕を図示する。 第 24図は、 2 0 0 0年 4月 1 7日を処理基準時 とした場合に生成される定期預金展開データであり、 第 25図は、 同日 における定期預金集約データである。 また、 第 2 6図は、 200 0年 6 月 1 0日における定期預金展開データであり、 第 27図は、 同日におけ る定期預金集約デ一夕である。 また、 第 2 8図は、 20 00年 9月 1 0 日における定期預金展開データであり、 第 29図は、 同日における定期 預金集約データである。 また、 第 3 0図は、 2 0 0 1年 3月 1 0日にお ける定期預金展開データであり、 第 3 1図は、 同日における定期預金集 約データである。 また、 第 3 2図は、 2 0 0 1年 4月 1 7日における定 期預金展開データであり、 第 3 3図は、 同日における定期預金集約デ一 夕である。
以上のようにして、 処理基準日およびそれ以降の将来に生ずるキヤッ シュ · フローを正確に表した定期預金預金集約デ一夕が生成され、 該定 期預金集約データは、 元となる定期預金取引情報より大幅に件数 ·デー 夕量が減少している。 かかる定期預金集約データを用いることにより、 いわゆるリテール取引などの非常に多件数になるキャッシュ · フロ一に ついても、 リスク管理システムにより、 処理することが可能となる。
(2. 4. 予約処理手段の構成例）
つぎに、 予約処理手段 1 8 0 3の構成について説明する。 第 34図 は、 予約処理手段 1 8 0 3の構成例を示すブロック図である。 同構成例 において、 予約処理手段 1 8 0 3は、 定期預金元帳'ファイル 2 2から為 替予約に関するデータを受け取る為替予約データ受取部 3 4 0 1と、 該 受取部 3 4 0 1の出力を受け取る買金額 ·売金額算出部 3 4 0 2と、 該 算出部 3 4 0 2の出力を受け取り、 リスク管理システム 3に為替予約集 約データを渡す為替予約集約データ蓄積部 3 4 0 3とを有している。 為替予約デ一夕受取部 3 4 0 1は、 定期預金元帳ファイルのデータを 読み取り、 ここから各為替予約に関するデータ、 たとえば、 満期日、 予 約日、 予約取引額 （外貨） 、 予約レートを抽出して、 これを出力する機 能を有する。 買金額 ·売金額算出部 3 4 0 2は、 為替予約に関するデ一 夕に基づいて各為替予約に関する買金額 （予約取引額及びそれの利息額 をいうものとする） 、 売金額 （買い取り金額を予約レートで邦貨に両替 した額をいう） 等を算出し、 これらを格納した為替予約情報集約レコー ドを各為替予約ごとに生成する機能を有する。 為替予約情報集約データ 蓄積部は、 為替予約情報集約レコードが集合してなる為替予約情報集約 データを蓄積する機能を有する。
( 2 . 5 . 予約処理手段の動作例）
次に、 第 3 5図に示す定期預金に関する取引例を用いて、 定期預金取 引情報展開手段および定期預金取引情報集約手段の動作例を説明する。 第 3 5図は、 定期預金に関する取引例のシナリオを示す図である。
該シナリォは以下の内容を有する。 2 0 0 0年 3月 1 0日に口座 # 1 が預入額 1，000,000米ドルで新規開設された。 同年 3月 1 1 日に口座 # 2が預入額 500, 000米ドルで新規開設された。 同年 8月 2 5日に口座 # 1について予約額米ドル 10, 000、 予約レート 1 0 7 . 5 0円で為替予 約がされた。 つづく 8月 2 6日に口座 # 2について予約額 500， 000米 ドル、 予約レー卜 1 0 6 . 9 8円で為替予約がされた。 同年 8月 2 7日 に口座 # 1について予約額 50, 000米ドル、 予約レート 1 0 7 . 0 0円 で為替予約がされた。 さらに同年 9月 2日に口座 # 1について予約額 2 0， 000米ドル、 予約レート 1 0 7 . 2 5円で為替予約がされた。 つぎ に同年 9月 1 1日に口座 # 1が満期解約された。 つづく 9月 1 0日に口 座 # 2が満期解約ざれた。
まず、 為替予約デ一夕受取部 3 4 0 1が定期預金元帳ファイル 2 2か ら為替予約に関するデータを抽出し、 これを受け取る。 第 3 6図に、 為 替予約データ受取部 3 4 0 1が定期預金元帳ファイル 2 2から取得した データの内容の一例を示す。 この例においては為替予約データ受取部 3 4 0 1は為替予約が行われている口座ごとに、 通貨、 入金額 （外貨） 、 交換レート、 利率、 預入日、 預入期間、 満期日、 予約日、 予約額、 予約 レートを受け取つている。 なお、 同図においては、 口座 # 1に関する 2 0 0 0年 8月 2 5日及び同年 8月 2 6日の為替予約に関するデータのみ 図示し、 2 0 0 0年 8月 2 7 日、 及び 2 0 0 0年 9月 2 日の為替予約に 関するデータの表示は省略されているが実際には受取部 3 4 0 1はこれ らのデータも取得する。
つぎに、 買金額 ·売金額算出部 3 4 0 2は第 3 6図に示すような為替 予約に関するデータを為替予約デ一夕受取部 3 4 0 1から受け取り、 こ れに基づいて、 所定の計算等を行う。 第 3 7図は、 買金額 ·売金額算出 部 3 4 0 2において行われる計算を説明するための図である。 買金額 - 売金額算出部 3 4 0 2は為替予約ごとに一つのレコードを生成する。 各 レコードは、 商品種類フィールド 3 7 0 1、 集約 I Dフィールド 3 7 0 2、 買通貨フィールド 3 7 0 3、 売通貨フィールド 3 7 0 4 , 日付フィ 一ルド 3 7 0 5， 買金額フィールド 3 7 0 6、 売金額フィ一ルド 3 7 0 7を有する。 買金額 ·売金額算出部 3 4 0 2は、 商品種類フィールドに 対応する金融商品を特定するコードを記入し、 集約 I Dフィールドには 為替予約情報集約データを識別するための識別子を記入し、 買通貨フィ 一ルドには、 外貨の種類を示すコードを記入し、 売通貨フィールドには 邦貨を示すコードを記入し、 買金額フィールドには予約金額を記入し、 売金額フィールドには該買金額フィールドに記入された額を予約レー卜 で売通貨に両替した場合の金額を算出し、 記入する。
つぎに、 買金額 ·売金額算出部 3 4 0 2は上記レコードを集約して為 替予約情報集約データを生成する。
集約は、 買金額■売金額算出部 3 4 0 2が上記レコードの内集約でき るもの同士をグループ化して抽出し、 同一グループに属するレコードの 買金額、 売金額の値を合算して一つの集約レコードにする。 この例の場 合、 グループ化の条件は同一 C F発生日かつ同一買通貨かつ同一売通貨 のレコードをグループ化する。 この例の場合展開レコード R 3 7 0 1 , R 3 7 0 3 , R 3 7 0 4は同一通貨かつ同一 C F発生日なので、 これら 3つのレコードがーつのグループを構成する。
第 3 8図から第 4 1図に、 買金額 ·売金 算出部 3 4 0 2によって生 成される為替予約情報集約データの例を示す。
第 3 8図は、 処理基準日を 2 0 0 0年 8月 2 5日とした場合の為替予 約情報集約データを示す。 この場合は買金額 ·売金額算出部 3 4 0 2が 生成するのはレコード R 3 7 0 1のみでこのレコードが集約の対象とな り、 その結果為替予約情報集約データにはレコード R 3 8 0 1のみ含ま れることとなる。
第 3 9図は、 処理基準日を 2 0 0 0年 8月 2 6日とした場合の為替予 約情報集約データを示す。 この場合は買金額 ·売金額算出部 3 4 0 2が 生成するのは.レコード R 3 7 0 1、 R 3 7 0 2でこの 2つのレコードが 集約の対象となり、 その結果為替予約情報集約データにはレコード R 3 9 0 1、 R 3 9 0 2が含まれることとなる。 第 40図は、 処理基準日を 2 0 0 0年 8月 2 7日とした場合の為替予 約情報集約データを示す。 この場合は買金額 ·売金額算出部 340 2が 生成するのはレコード R 3 7 0 1、 R 3 7 0 2、 R 37 0 3でこの 3つ のレコ一ドが集約の対象となり、 その結果為替予約情報集約データには レコード R 3 7 0 1と R 3 70 3とが集約されたレコード R40 0 1 と、 レコード R 3 7 02が集約された R 40 0 2が含まれることとな る。 .
第 4 1図は、 処理基準日を 2000年 9月 2日とした場合の為替予約 情報集約データを示す。 この場合は買金額 ·売金額算出部 3402が生 成するのはレコード R 37 0 1、 R 3 7 0 2、 R 3 7 0 3、 R 3 7 04 でこの 4つのレコードが集約の対象となり、 その結果為替予約情報集約 デー夕にはレコ一ド R 3 7 0 1、 R 3 7 0 3 , R 3 704が集約された レコード R 4 1 0 1と、 レコード R 3 7 0 2が集約された R 41 0 2が 含まれることとなる。
これら為替予約情報集約レコードは為替予約集約データとして為替予 約集約データ蓄積部 340 3に蓄積され、 必要に応じてリスク管理シス テム 3に供給される。 なお、 集約レコードのフォーマッ トは、 リスク管 理システム 3の仕様に合致したフォーマツトであることが望ましいが、 集約データをリスク管理システム 3の仕様に合致したフォーマツトに変 換する図示しないィンタ一フェイス手段を介してリスク管理システム 3 に為替予約集約デー夕を供給するようにしてもよい。
以上のようにして、 将来 （満期日） に生ずる外貨 ·邦貨双方のキヤッ シュ · フローを正確に表した為替予約集約データが生成され、 該集約デ —夕は、 もととなる取引情報より大幅に件数 ·データ量が減少してい る。 かかる集約データを用いることにより、 いわゆるリテール取引など の非常に多件数になるキャッシュ · フローについても、 リスク管理シス テムにより処理することが可能となる。
( 3 . カードローン取引情報集約部）
つぎに、 カードローン取引情報集約部 2 8について説明する。
( 3 . 1 . 構成例）
カードローン元帳ファイル 2 3に記録されている取引情報を集約する カードローン取引情報集約部 2 8の構成例について第 4 2図を参照して 説明する。
同図に示すように、 カードローン取引情報集約部 2 8は、 カードロー ン取引情報展開手段 （以下、 「カードローン展開手段」 と略す） 4 2 0 1と、 カードローン取引情報集約手段 （以下、 「カードローン集約手 段」 と略す） 4 2 0 2とを具備する。
力一ドロ一ン展開手段 4 2 0 1はカードローン元帳ファイル 2 3から カードローン取引情報データを受け取り、 該取引情報データに基づいて カードローン展開データを生成し、 出力するように機能する。 力一ドロ ーン集約手段 4 2 0 2はカードローン展開手段 4 2 0 1から力一ドロ一 ン展開データを受け取り、 該展開データに基づいてカードローン集約デ —夕を生成し、 これをリスク管理システム 3に出力するように機能す る。
第 4 2図に示すように、 カードローン展開手段 4 2 0 1は、 カード口 ーン元帳ファイル 2 3に接続されたカードローン取引情報取得部 4 2 0 3と、 該取引情報取得部 4 2 0 3に接続されたキヤッシュ ·ムーブメン 卜処理部 4 2 0 4および利息キャッシュ · フロー処理部 4 2 0 6と、 該 処理部 4 2 0 4及び 4 2 0 6に接続された展開データ蓄積部 4 2 0 5と を有している。
取引情報取得部 4 2 0 3は、 カードローン元帳ファイル 2 3から金銭 の移動を計算するために必要なデータを、 該ファイルを構成するひとつ のレコ一ドごとに取得する。 カードローン元帳ファイル 2 3のレコード には、 口座番号、 利率、 約定返済日、 毎回返済額、 返還元金、 返済利 息、 融資残高、 次回残高積数、 次回利息額、 次回返済日、 最終更新日を 含んでいる。 取引情報取得部 4 2 0 3は、 レコードごとに必要なデータ を読み出し、 キャッシュ ·ムーブメント処理部 4 2 0 4および利息キヤ ッシュ · フロー処理部 4 2 0 6に渡す機能を有する。
キャッシュ ·ム一ブメント処理部 4 2 0 4は、 カードローン元帳ファ ィル 2 3のレコ一ドごとに取引情報取得部 4 2 0 3が取得したデータに 基づいて処理基準日に発生した元金及び利息の変動、 および処理基準日 の融資残高を記録した力一ドロ一ン展開レコードを生成する。
一方、 利息キャッシュ · フ口一処理部 4 2 0 6は、 取引情報取得部 4 2 0 3が取得したデータに基づいてカードローン元帳ファイル 2 3のレ コードごとに、 次回約定返済日における元金 ·利息金額を計算し、 これ を展開レコードに格納してカードロ一ン展開データ蓄積部 4 2 0 5に渡 す機能を有する。
力一ドローン展開データ蓄積部 4 2 0 5は、 キャッシュ ·ムーブメン ト処理部 4 2 0 4および利息キャッシュ · フロー処理部 4 2 0 6から供 給されるレコードを蓄積してカードローン展開デ一タとして蓄積する機 能を有する。 力一ドロ一ン取引情報展開手段 4 2 0 1がカードローン元 帳ファイル 2 3のすベてのレコードについて処理を行うと、 カードロー ン展開データが完成する。
カードローン取引情報集約手段 4 2 0 2は、 前記カードローン展開デ 一夕蓄積部 4 2 0 5に接続された集約対象抽出部 4 2 0 7と、 集約対象 抽出部 4 2 0 7に接続された集約内容計算部 4 2 0 8と、 集約内容計算 部 4 2 0 8に接続されたカードローン預金集約データ蓄積部 4 2 0 9と を有 9'る。 集約対象抽出部 4 2 0 7は、 カードローン展開データ蓄積部 4 2 0 5 からカードローン展開データのレコ一ド群の内、 集約できるもの同士を グループ化して抽出する機能を有する。 集約は同一のキャッシュ · フロ —発生日 （処理基準日を含む） にかかる展開レコードを、 一の集約レコ —ドに集約するように機能する。 なお、 グループ化する方法としては、 たとえばキャッシュ · フロー発生日をキーにして展開レコードのソート を行い、 キャッシュ · フロー発生日が先のレコードと異なる場合は、 別 のグループとする等により実現する。
次に、 集約内容計算部 4 2 0 8は、 ダル一プ化されたレコード群を集 約対象抽出部 4 2 0 7から受け取ると、 各グループの元金、 利息、 預金 残高を合算して、 一の集約レコードに格納し、 該集約レコードをカード ローン集約データ蓄積部 4 2 0 9に送るように機能する。 グループとな らない展開レコードについては、 合算を行わずに一つの集約レコードを 生成し、 カードローン集約データ蓄積部 4 2 0 9に送るように機能す る。
すべてのグループについて処理が行われ、 集約レコードの集合である カードローン集約データが完成し、 カードローン集約データ蓄積部 4 2 0 9は、 完成したカードローン集約データを蓄積し、 蓄積されたカード ローン集約デ一タをリスク管理システム 3に供給するように機能する。 なお、 集約レコードのフォーマットは、 リスク管理システム 3の仕様 に合致したフォーマツトであることが望ましいが、 カードローン集約デ 一夕をリスク管理システム 3の仕様に合致したフォーマツトに変換する 図示しないインターフェイス手段を介してリスク管理システム 3に力一 ドローン集約データを供給するようにしてもよい。
( 3 . 2 . 動作例）
次に、 第 4 3図に示す力一ドロ一ン預金に関する取引例を用いて、 力 —ドローン取引情報集約部 2 8の動作例を説明する。 第 43図は、 カー ドローンに関する取引例のシナリオを示す図である。 該シナリオは、 2 00 0年 2月 1 0日に、 口一ン口座 # 1について借入金額 2 0 0， 0 0 0円、 約定利率 9.00%、 約定返済日 1 2日、 毎回返済 20,' 000円と いう条件のカード口一ンが発生し、 またローン口座 # 2について、 借入 金額 1 0 0 , 0 0 0円、 約定利率 9.00%、 約定返済日 27日、 毎回返 済額 20, 000円が発生し、 以降毎月 1 2日に、 ローン口座 # 1について 返済が行われ、 毎月 2 7 日に、 口一ン口座 # 2について返済が行われ る。
第 44図は、 2 00 0年 2月 1 0日において、 カードローン元帳ファ ィル 2 3に格納されている取引情報例を示す概念図であり、 第 45図 は、 同日においてカードロ一ン展開手段 420 1によって生成される力 一ドロ一ン展開データを示す図であり、 第 46図は、 同日において力一 ドロ一ン集約手段 42 0 2によって生成されるカードロ一ン集約デ一夕 を示す図である。
この場合において、 第 45図に示す展開データは複数の展開レコード R45 0 1、 R 450 2 , R 45 0 3 , R 45 04からなり、 各レコー ドは口座番号フィ一ルド 45 0 1、 通貨フィールド 45 02、 CF発生 日フィールド 45 0 3、 入金元金フィールド 45 04、 出金元金フィー ルド 450 5、 出金利息額フィ一ルド 450 6、 残高フィ一ルド 45 0 7を有している。
また、 カードローン集約データは集約レコード R 46 0 1、 R 46 0 2， R 46 0 3 , R4604からなり、 各集約レコードは、 商品種類フ ィールド 46 0 1 , 集約 I Dフィールド 46 0 2， 通貨フィールド 46 03, 返済日コードフィールド 46 04， 日付フィールド 460 5, 元 金移動額フィールド 46 0 6 , 利息移動額フィールド 460 7、 残高フ ィールド 4 6 0 8を有している。 商品種類フィールドには対応する金融 商品を特定するコードが記入される。 集約 I Dは、 カードローン集約デ 一夕を識別するための識別子である。
まず、 取引情報取得部 4 2 0 3は、 第 4 4図に示すようなデ一夕を力 —ドローン元帳ファイル 2 3から取得する。
つぎに、 キャッシュ ·ムーブメント処理部 4 2 0 4は、 力一ドロ一ン 取引情報取得部 4 2 0 3のデータに基づいて、 口座 # 1について借入金 2 0万円のローンが発生したことを判断し、 展開レコード R 4 5 0 1を 生成する。 同様に、 口座 # 2について借入金 1 0万円のローンが発生し たことを判断し、 展開レコード R 4 5 0 2を生成する。 各レコードのフ ィールドには対応するデータがキャッシュ ·ムーブメント処理部 4 2 0 2によって記入される。
一方、 利息キャッシュ ' フロー処理部 4 2 0 6は、 口座 # 1の次回返 済日に関する展開レコード R 4 5 0 3を生成し、 口座 # 2の次回返済日 に関する展開レコード R 4 5 0 4を生成する。 なお利子額は利息キヤッ シュ · フロー処理部によって計算したものをレコードに記入してもよい し、 また、 カード口一ン取引情報取得部 4 2 0 3が、 第 4 4図のような 元帳ファイルから利子額を取得してこれを利息キャッシュ ■ フロー処理 部がレコードにコピーするようにしてもよい。
上記のようにして生成された展開レコード R 4 5 0 1〜R 4 5 0 4 は、 上記処理部 4 2 0 4 , 4 2 0 6から展開デ一夕蓄積部 4 2 0 5に渡 され、 展開データ蓄積部 4 2 0 5はこれを蓄積する。
カードローン集約手段 4 2 0 2は、 集約対象抽出部 4 2 0 7によって 展開デ一タ蓄積部 4 2 0 5から展開データのレコード群の内集約できる もの同士をグループ化して抽出する。 力一ドローン集約手段の集約の場 合、 同一 C F発生日、 同一通貨かつ同一返済日の展開レコードをダル一 プ化する。 本シナリオにおいては、 この条件を満たす 2以上の展開レコ ードがないので、 集約対象抽出部 4 2 0 7におけるグループ化は行われ ず、 展開レコード R 4 5 0 1 , R 4 5 0 2 , R 4 5 0 3 , R 4 5 0 4に それぞれ対応する集約レコード R 4 6 0 1 、 R 4 6 0 3 , R 4 6 0 2 , R 4 6 0 4が集約内容計算部 4 2 0 8により生成され、 第 4 6図に示す 力一ドロ一ン集約データのようになる。 なお、 複数のレコードが集約さ れる場合には、 集約内容計算部 4 2 0 8によって、 元金移動額および利 息移動額が合算され、 集約レコードの元金移動額フィールド 4 6 0 6、 利息移動額フィールド 4 6 0 7、 残高フィールド 4 6 0 8に記入され る。
以降、 同様にして約定日の到来時には、 カードローン展開手段 4 2 0 1によって展開データが生成され、 該展開データに基づいてカードロー ン集約手段 4 2 0 2によってカードローン集約データが生成される。 第 4 7図は、 2 0 0 0年 3月 1 2日において、 カードローン元帳ファイル 2 3に格納されている取引情報例を示す概念図であり、 第 4 8図は、 同 日においてカードローン展開手段 4 2 0 1によって生成される展開デー 夕を示す図であり、 第 4 9図は、 同日においてカードローン集約手段 4 2 0 2によって生成されるカードローン集約データを示す図である。 ま た、 第 5 0図は、 2 0 0 0年 3月 2 7日において、 カードローン元帳フ アイル 2 3に格納されている取引情報例を示す概念図であり、 第 5 1図 は、 同日においてカードローン展開手段 4 2 0 1によって生成される展 開データを示す図であり、 第 5 2図は、 同日においてカードローン集約 手段 4 2 0 2によって生成されるカードローン集約データを示す図であ る。
以上のようにして、 カードローン取引に関して処理基準日および将来 生ずるキヤッシュ · フローを正確に表したカードロ一ン集約データが生 成され、 該集約データは、 元となる取引情報より大幅に件数 ·データ量 が減少している。 かかる集約データを用いることにより、 いわゆるリテ —ル取引などの非常に多件数になるキャッシュ · フローについても、 リ スク管理システムにより処理することが可能となる。
( 4 . 目的別ローン ·住宅ローン取引情報集約部）
つぎに、 マイカーローン、 プライダル ' ローン、 トラベル · ローンな どの目的別ローンと、 住宅ローンとに関する取引情報を集約する目的別 ローン ·住宅口一ン取引情報集約部 2 9について説明する。
( 4 . 1 . 構成例）
第 5 3図は、 目的別ローン ·住宅口一ン取引情報集約部 2 9の構成例 を示すブロック図である。
目的別ローン ·住宅ローン取引情報集約部 2 9は、 目的別ローンに関 する取引情報を集約するための目的別ローン取引情報展開手段 5 3 0 1 と、 固定 ·変動別展開データ分配手段 5 3 0 2と、 固定分展開データ集 約手段 5 3 0 3と、 変動分展開データ集約手段 5 3 0 4とを有するとと もに、 住宅口一ンに関する取引情報を集約するための住宅ローン取引情 報展開手段 5 3 0 6と、 固定 ·変動 · C a p別展開データ分配手段 5 3 0 7と、 固定分展開データ集約手段 5 3 0 8と、 変動分展開データ集約 手段 5 3 0 9と、 C a p分展開デ一夕集約手段 5 3 1 0とを有し、 さら に固定分集約デ一夕マージ手段 5 3 0 5と変動分集約データマージ手段 5 3 1 1とを有する。
目的別ローン展開手段 5 3 0 1は、 目的別口一ン元崞ファイル 2 4か ら目的別口一ン取引情報デ一夕を受け取り、 該取引情報データに基づい て目的別ローン展開データを生成し、 出力するように機能する。 第 5 4 図は、 目的別ローン取引情報展開手段 5 3 0 1の構成例を示すブロック 図である。 該展開手段 5 3 0 1は、 目的別ローン元帳ファイル 2 4に接 続された目的別ローン取引情報取得部 5 4 0 1 と、 該取引情報取得部 5
4 0 1に接続されたキャッシュ · ムーブメント処理部 5 4 0 2および元 金等キャッシュ · フロー処理部 5 4 0 4と、 該処理部 5 4 0 2及び 5 4 0 4に接続された展開データ蓄積部 5 4 0 5とを有している。
目的別ローン展開手段 5 3 0 1の各構成要素は、 元金等キャッシュ · フロ一処理部 5 4 0 4が各口座についての元金、 利息および預金残高の 変動毎に展開レコードを生成する点を除いて、 第 4 2図に示すカード口 ーン取引情報展開手段 4 2 0 1の対応する構成要素と同様に動作するも のである。
固定 ·変動別展開データ分配手段 5 3 0 2は、 目的別ローン展開デー 夕を固定金利分に関する展開データと、 変動金利分に関する展開データ とに分けて出力する機能を有する。
固定分展開データ集約手段 5 3 0 3は固定 ·変動別展開データ分配手 段 5 3 0 2から固定金利分に関する展開データを受け取り、 該展開デー 夕に基づいて目的別口一ン展開データの固定金利分に関する展開データ を集約した固定分目的別ローン集約データを生成し、 これを出力するよ うに機能する。
第 5 5図は、 住宅ローン取引情報展開手段 5 3 0 6の構成例を示すブ ロック図である。 該展開手段 5 3 0 6は、 住宅ローン元帳ファイル 2 5 に接続された住宅ローン取引情報取得部 5 5 0 1と、 該取引情報取得部
5 5 0 1 ·に接続されたキヤッシュ ·ム一ブメント処理部 5 5 0 2、 元金 等キヤッシュ · フロー処理部 5 5 0 3、 および C a p処理部 5 5 0 5 と、 該処理部 5 5 0 2、 5 5 0 3及び 5 5 0 5に接続された展開データ 蓄積部 5 5 0 4とを有している。
住宅ローン展開手段 5 3 0 6は、 住宅ローン元帳ファイル 2 5から住 宅ローン取引情報データを受け取り、 該取引情報データに基づいて住宅 ローン展開データを生成し、 出力するように機能する。
住宅ローン取引情報展開手段 5 3 0 6の各構成要素は、 C a p処理部 5 5 0 5を除いて、 第 5 4図に示す目的別ローン取引情報展開手段 5 3 0 1の対応する構成要素と同様に動作するものである。
変動分展開データ集約手段 5 3 0 4は固定 ·変動別展開データ分配手 段 5 3 0 2から変動金利分に関する展開データを受け取り、 該展開デ一 夕に基づいて目的別ローン展開データの変動金利分に関する展開データ を集約した変動分目的別ローン集約データを生成し、 これを出力するよ うに機能する。
固定 ·変動 · C a p別展開データ分配手段 5 3 0 7は、 住宅口一ン展 開データを固定金利分に関する展開データ、 変動金利分に関する展開デ —夕及び C a p分に関する展開データとに分けて出力する機能を有す る。
固定分展開デ一夕集約手段 5 3 0 8は固定 ·変動 · C a p別展開デ一 タ分配手段 5 3 0 7から固定金利分に関する展開データを受け取り、 該 展開データに基づいて住宅ローン展開データの固定金利分に関する展開 データを集約した固定分住宅ローン集約データを生成し、 これを出力す るように機能する。
変動分展開デ一タ集約手段 5 3 0 9は固定 ·変動 · C a p別展開デー 夕分配手段 5 3 0 7から変動金利分に関する展開デ一夕を受け取り、 該 展開データに基づいて住宅ローン展開データの変動金利分に関する展開 デ一夕を集約した変動分住宅ローン集約データを生成し、 これを出力す るように機能する。
C a p分展開データ集約手段 5 3 1 0は固定 ·変動 · C a p別展開デ —タ分配手段 5 3 0 7から C a p分に関する展開データを受け取り、 該 展開デ一夕に基づいて住宅ローン展開デ一夕の C a p分に関する展開デ 一夕を集約した C a p分集約データを生成し、 これをリスク管理システ ム 3に渡すように機能する。
固定分集約データマージ手段 5 3 0 5は、 固定分展開データ集約手段 5 3 0 3および 5 3 0 8からそれぞれ固定金利分の展開データを受け取 り、 これを一つの固定分集約デ一夕にし、 リスク管理システム 3に渡す 機能を有する。
変動分集約データマージ手段 5 3 1 1は、 変動分展開データ集約手段 5 3 0 4および 5 3 0 9からそれぞれ変動金利分に関する展開データを 受け取り、 これを一つの変動分集約データにし、 リスク管理システム 3 に渡す機能を有する。
( 4 . 2 . 目的別ローン '住宅ローン取引情報集約部の動作例） つぎに、 第 5 6図に示す目的別ローン ·住宅ローンに関する取引例を 用いて、 目的別口一ン ·住宅ローン取引情報集約部 2 9の動作例を説明 する。 第 5 6図は、 目的別ローン ·住宅ローンに関する取引例のシナリ ォを示す図である。 該シナリオは、 第 5 7図に示す内容を有するローン 口座 # 1〜# 6が 2 0 0 0年 2月 1 0日に開設され、 以降各口座につい て毎月各約定日に所定額の返済が発生するものである。
目的別ローン元帳ファイル 2 4には、 第 5 7図に示すように、 口座 # 2 , # 3， # 5に対応するレコード R 5 7 0 2 , R 5 7 0 3、 R 5 7 0 5が記録されており、 目的別ローン取引情報展開手段 5 3 0 1は、 該レ コードを取得して、 これからそれぞれ固定金利分、 変動金利分に関する 展開データを生成する。 該生成された展開データは分配手段 5 3 0 2に よって、 固定金利分に関する展開データと変動金利分に関する展開デー 夕とに分けられ、 それぞれ固定分展開データ集約手段 5 3 0 3と変動分 展開デ一夕集約手段 5 3 0 4に渡される。 第 5 8図は、 分配手段 5 3 0 2から固定分展開データ集約手段 5 3 0 3に渡される固定金利分に関す る展開デ一夕を示す図であり、 第 5 9図は、 分配手段 5 3 0 2から変動 分展開データ集約手段 5 3 0 4に渡される変動金利分に関する展開デー 夕を示す図である。
固定分展開データ集約手段 5 3 0 3と変動分展開データ集約手段 5 3 0 4とはそれぞれ、 展開データの各レコードを返済日毎かつポ一ナス返 済毎にグループ化し、 同一グループ内のレコードの元金、 利息金額、 融 資残高を合算して集約データを生成する。
一方、 住宅ローン元帳ファイル 2 5には、 第 5 7図に示すように、 口 座 # 1 , # 4， # 6に対応するレコード R 5 7 0 1， R 5 7 0 4、 R 5 7 0 6が記録されており、 住宅ローン取引情報展開手段 5 3 0 6は、 該 レコードを取得して、 これからそれぞれ固定金利分、 変動金利分、 C a p分に関する展開データを生成する。 該生成された展開データは分配手 段 5 3 0 7によって、 固定金利分に関する展開データ、 変動金利分に関 する展開デ一夕、 C a p分に関する展開データとに分けられ、 それぞれ 固定分展開データ集約手段 5 3 0 8、 変動分展開データ集約手段 5 3 0 9、 C a p分展開データ集約手段 5 3 1 0に渡される。 第 6 0図は、 分 配手段 5 3 0 7から固定分展開データ集約手段 5 3 0 8に渡される固定 金利分に関する展開データを示す図であり、 第 6 1図は、 分配手段 5 3 0 7から変動分展開データ集約手段 5 3 0 9に渡される変動金利分に関 する展開データを示す図であり、 第 6 2図は、 分配手段 5 3 0 7から C a p分展開データ集約手段 5 3 1 0に渡される C a p分に関する展開デ 一夕を示す図である。
固定分展開デ一夕集約手段 5 3 0 8と変動分展開データ集約手段 5 3 0 9とはそれぞれ、 展開データの各レコードを返済日毎かつポ一ナス返 済毎にグループ化し、 同一グループ内のレコードの元金、 利息金額、 融 資残高を合算して集約データを生成する。 ' C a p分展開データ集約手段 5 3 1 0は、 展開データのレコ一ドを同 一返済曰かつ同一 S t r i k eを有するレコードごとにグループ化し、 同一グループ内のレコードの残高を合算して集約デ一夕を生成する。 第 6 3図に C a p分展開デ一夕集約手段 5 3 1 0により生成される集約デ 一夕の例を示す。
固定分集約デ一夕マージ手段 5 3 0 5は、 固定分展開データ集約手段 5 3 0 3および 5 3 0 8から固定分集約データを受け取り、 一つの固定 分集約データを生成して、 これをリスク管理システム 3に渡す。 第 6 4 図に、 固定分集約データマ一ジ手段 5 3 0 5により生成されリスク管理 システム 3に渡される固定分集約データを示す。 これにより、 目的別口 ーン及び住宅ローンに関する固定金利に関するキャッシュ · フローを一 の集約データとしてリスク管理システム 3に供給することが可能とな る。
同様に、 変動分集約データマージ手段 5 3 1 1は、 変動分展開デ一タ 集約手段 5 3 0 4および 5 3 0 9から変動分集約データを受け取り、 一 つの固定分集約データを生成して、 これをリスク管理システム 3に渡 す。 第 6 5図に、 変動分集約データマージ手段 5 3 1 1により生成され リスク管理システム 3に渡される変動分集約デ一夕の例を示す。 これに より、 目的別ローン及び住宅ローンに関する変動金利に関するキヤッシ ュ · フローを一の集約データとしてリスク管理システム 3に供給するこ とが可能となる。
本発明によれば、 普通預金、 定期預金、 各種ローンについて外貨邦貨 に関わりなく、 キャッシュ · フローを正確に表す集約されたデータをリ スク管理システムに供給することが可能となる。

Claims

請求の範囲
1 . 取引情報記憶装置に格納された取引情報に基づいて、 リスク管理に 用いるための取引情報を集約して、 これをリスク管理システムに供給す るための金融取引に関する取引情報を集約する装置であって、 取引情報 記憶装置から取引情報を取得して、 該取引情報に基づいて金銭移動額の 発生を表す展開レコードを生成し、 所定の集約条件に基づいて展開レコ 一ドをグループ化し、 同一グループに属する複数の展開レコードから集 約レコ一ドを生成することを特徴とする装置。
2 . 請求の範囲第 1項に記載の装置において、 該装置は取引情報記憶装 置に格納されている元帳ファイル毎に設けられた取引情報集約部を有 し、 各取引情報集約部は、 対応する元帳ファイルに格納されている金融 商品の性質に応じて前記所定の集約条件が定められていることを特徴と する装置。
3 . 請求の範囲第 2項に記載の装置において、 取引情報集約部は、 元 金、 利息、 及び残高の少なくとも一つの変動日及びその変動量を格納し た展開レコードを生成する取引情報展開手段と、 該展開レコードを集約 条件に基づいてグループ化し、 グループ化された展開レコードの元金、 利息、 及び残高の少なくとも一つを合算することにより集約レコードを 生成する取引情報集約手段とを具備していることを特徴とする装置。
4 . 請求の範囲第 3項に記載の装置において、 取引情報展開手段は、 元 帳ファイルに接続された取引情報取得部と、 該取引情報取得部に接続さ れたキャッシュ ·ムーブメント処理部およびキャッシュ · フロー処理部 と、 これら処理部に接続された展開データ蓄積部とを有しており、 キヤ ッシュ ' ムーブメント処理部は、 取引情報取得部が取得したデータに基 づいて元帳ファイルのレコードごとに、 処理基準日に発生した元金及び 利息の変動を記録した展開レコードを生成し、 キャッシュ · フロー処理 部は、 取引情報取得部が取得したデータに基づいて元帳ファイルのレコ —ドごとに、 次回利盛日の利息を算出し、 これを展開レコードに格納し て展開データ蓄積部に渡すことを特徴とする装置。
5 . 請求の範囲第 3項に記載の装置において、 前記取引情報集約手段 は、 前記取引情報展開手段の出力に接続された集約対象抽出部と、 集約 対象抽出部に接続された集約内容計算部と、 集約内容計算部に接続され た集約データ蓄積部とを有し、 集約対象抽出部は、 前記取引情報展開手 段から展開レコードを受け取り、 該受け取った展開レコードを所定の集 約条件に基づいてグループ化し、 集約内容計算部は、 グループ化された 展開レコードを集約対象抽出部から受け取り、 各グループの元金の移 動、 利息の移動、 次回利盛日及び融資残高の少なくとも一つを合算し て、 一の集約レコードに格納し、 該集約レコードを集約データ蓄積部に 送ることを特徴とする装置。
6 . 取弓!情報記憶装置に格納された取引情報に基づいて、 リスク管理に 用いるための取引情報を集約して、 これをリスク管理システムに供給す るための金融取引に関する取引情報を集約する方法であって、 取引情報 記憶装置から取引情報を取得して、 該取引情報に基づいて元金、 利息、 融資残高の少なくとも一つの変化を表す展開.レコードを生成する展開レ コード生成工程と、 所定の集約条件に基づいて展開レコードをグループ ィ匕し、 同一グループに属する複数の展開レコードから一の集約レコード を生成する集約レコード生成工程とを具備することを特徴とする方法。
7 . 請求の範囲第 6項に記載の方法において、 前記展開レコード生成ェ 程は、 取引情報に基づいて処理基準日に発生した元金及び利息の変動を 記録した第 1の展開レコードを生成する工程と、 処理基準日以降発生す ることが予測される元金、 利息、 融資残高の少なくとも一つの変動額を 記録した第 2の展開レコードを生成する工程とを具備することを特徴と する方法。
8 . 請求の範囲第 6項に記載の方法において、 前記集約レコード生成ェ 程は、 展開レコ一ドを所定の集約条件に基づいてグループ化する工程 と、 グループ化された展開レコードについて各グループの元金の移動、 利息の移動、 次回利盛日及び融資残高の少なくとも一つを合算して、 一 の集約レコードに格納する工程とを具備することを特徴とする方法。
9 . コンピュータをして請求の範囲第 1項から第 5項のいずれかに記載 の装置として機能させることを特徴とするプログラムを記録した情報記 録媒体。
1 0 . コンピュータをして請求の範囲第 1項から第 5項のいずれかに記 載の装置として機能させることを特徴とするプログラム。
1 1 . 請求の範囲第 6項から第 8項のいずれかに記載の方法をコンビュ —夕の実行させるためのプログラムを記録したコンピュータ読み取り可 能な記録媒体。
1 2 . 請求の範囲第 6項から第 8項のいずれかに記載の方法をコンビュ 一夕の実行させるためのプログラム。
PCT/JP2002/000976 2001-02-09 2002-02-06 Dispositif permettant l'integration de donnees de transaction relatives aux transactions financieres WO2002065365A1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
EP02711339A EP1359525A4 (en) 2001-02-09 2002-02-06 DEVICE FOR INTEGRATION OF TRANSACTION DATA RELATING TO FINANCIAL TRANSACTIONS
US14/071,133 US20140114821A1 (en) 2001-02-09 2013-11-04 Apparatus for consolidating financial transaction information

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2001034710A JP4701510B2 (ja) 2001-02-09 2001-02-09 金融取引に関する取引情報を集約する装置、及びその方法
JP2001-034710 2001-02-09

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US10/240,967 A-371-Of-International US20030163398A1 (en) 2001-02-09 2002-02-06 Device for integrating transaction information on finantial transaction
US14/071,133 Continuation US20140114821A1 (en) 2001-02-09 2013-11-04 Apparatus for consolidating financial transaction information

Publications (1)

Publication Number Publication Date
WO2002065365A1 true WO2002065365A1 (fr) 2002-08-22

Family

ID=18898262

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2002/000976 WO2002065365A1 (fr) 2001-02-09 2002-02-06 Dispositif permettant l'integration de donnees de transaction relatives aux transactions financieres

Country Status (5)

Country Link
US (2) US20030163398A1 (ja)
EP (1) EP1359525A4 (ja)
JP (1) JP4701510B2 (ja)
CN (1) CN1460219A (ja)
WO (1) WO2002065365A1 (ja)

Families Citing this family (34)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP4701510B2 (ja) * 2001-02-09 2011-06-15 ソニー株式会社 金融取引に関する取引情報を集約する装置、及びその方法
US8209246B2 (en) 2001-03-20 2012-06-26 Goldman, Sachs & Co. Proprietary risk management clearinghouse
US8069105B2 (en) * 2001-03-20 2011-11-29 Goldman Sachs & Co. Hedge fund risk management
US8121937B2 (en) 2001-03-20 2012-02-21 Goldman Sachs & Co. Gaming industry risk management clearinghouse
US8140415B2 (en) * 2001-03-20 2012-03-20 Goldman Sachs & Co. Automated global risk management
US9412123B2 (en) 2003-07-01 2016-08-09 The 41St Parameter, Inc. Keystroke analysis
US10999298B2 (en) 2004-03-02 2021-05-04 The 41St Parameter, Inc. Method and system for identifying users and detecting fraud by use of the internet
US8442953B2 (en) 2004-07-02 2013-05-14 Goldman, Sachs & Co. Method, system, apparatus, program code and means for determining a redundancy of information
US8510300B2 (en) 2004-07-02 2013-08-13 Goldman, Sachs & Co. Systems and methods for managing information associated with legal, compliance and regulatory risk
US8762191B2 (en) 2004-07-02 2014-06-24 Goldman, Sachs & Co. Systems, methods, apparatus, and schema for storing, managing and retrieving information
US8996481B2 (en) 2004-07-02 2015-03-31 Goldman, Sach & Co. Method, system, apparatus, program code and means for identifying and extracting information
US10127130B2 (en) 2005-03-18 2018-11-13 Salesforce.Com Identifying contributors that explain differences between a data set and a subset of the data set
US7720822B1 (en) * 2005-03-18 2010-05-18 Beyondcore, Inc. Quality management in a data-processing environment
US8782087B2 (en) 2005-03-18 2014-07-15 Beyondcore, Inc. Analyzing large data sets to find deviation patterns
US7630924B1 (en) * 2005-04-20 2009-12-08 Authorize.Net Llc Transaction velocity counting for fraud detection
US11301585B2 (en) 2005-12-16 2022-04-12 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US8938671B2 (en) 2005-12-16 2015-01-20 The 41St Parameter, Inc. Methods and apparatus for securely displaying digital images
US8151327B2 (en) 2006-03-31 2012-04-03 The 41St Parameter, Inc. Systems and methods for detection of session tampering and fraud prevention
US8210425B2 (en) 2008-04-25 2012-07-03 Netsuite, Inc. Multiple rate currency consolidator
US9112850B1 (en) 2009-03-25 2015-08-18 The 41St Parameter, Inc. Systems and methods of sharing information through a tag-based consortium
US8706615B2 (en) * 2009-12-04 2014-04-22 Robert A. Merkle Systems and methods for evaluating the ability of borrowers to repay loans
US10754913B2 (en) 2011-11-15 2020-08-25 Tapad, Inc. System and method for analyzing user device information
US10796232B2 (en) 2011-12-04 2020-10-06 Salesforce.Com, Inc. Explaining differences between predicted outcomes and actual outcomes of a process
US10802687B2 (en) 2011-12-04 2020-10-13 Salesforce.Com, Inc. Displaying differences between different data sets of a process
US9633201B1 (en) 2012-03-01 2017-04-25 The 41St Parameter, Inc. Methods and systems for fraud containment
US9521551B2 (en) 2012-03-22 2016-12-13 The 41St Parameter, Inc. Methods and systems for persistent cross-application mobile device identification
WO2014019051A1 (en) * 2012-07-31 2014-02-06 Ftse Tmx Global Debt Capital Markets Inc. Server and method for processing data records
EP2880619A1 (en) 2012-08-02 2015-06-10 The 41st Parameter, Inc. Systems and methods for accessing records via derivative locators
WO2014078569A1 (en) 2012-11-14 2014-05-22 The 41St Parameter, Inc. Systems and methods of global identification
US10902327B1 (en) 2013-08-30 2021-01-26 The 41St Parameter, Inc. System and method for device identification and uniqueness
US10091312B1 (en) 2014-10-14 2018-10-02 The 41St Parameter, Inc. Data structures for intelligently resolving deterministic and probabilistic device identifiers to device profiles and/or groups
JP6875200B2 (ja) * 2017-06-02 2021-05-19 株式会社Ｑｕｉｃｋ リスク評価システム、リスク評価方法及びリスク評価プログラム
JP7269022B2 (ja) * 2019-02-04 2023-05-08 株式会社オービック 利息計算装置、利息計算方法および利息計算プログラム
US11403210B1 (en) * 2019-07-26 2022-08-02 G4S Retail Solutions (USA) Inc. Virtual simulation environment for testing functionality of physical cash handling devices

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05225222A (ja) * 1992-02-10 1993-09-03 Hitachi Ltd 資金シフトシミュレーションシステム
JPH1186089A (ja) * 1997-09-03 1999-03-30 Fujitsu Ltd 在高管理システム
JPH11175602A (ja) * 1997-12-12 1999-07-02 Fujitsu Ltd 信用リスク計測装置
JPH11296610A (ja) * 1998-04-10 1999-10-29 Bank Of Tokyo Mitsubishi Ltd 資金管理システム

Family Cites Families (30)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB1351937A (en) * 1970-06-04 1974-05-15 De La Rue Instr Cash dispensing apparatus
US4752877A (en) * 1984-03-08 1988-06-21 College Savings Bank Method and apparatus for funding a future liability of uncertain cost
US4742457A (en) * 1985-08-27 1988-05-03 Trans Texas Holdings Corporation System and method of investment management including means to adjust deposit and loan accounts for inflation
US5812988A (en) * 1993-12-06 1998-09-22 Investments Analytic, Inc. Method and system for jointly estimating cash flows, simulated returns, risk measures and present values for a plurality of assets
US5890140A (en) * 1995-02-22 1999-03-30 Citibank, N.A. System for communicating with an electronic delivery system that integrates global financial services
WO1996030852A1 (en) * 1995-03-30 1996-10-03 Hogan Systems, Inc. Method of and system for financial institution budgeting and planning
US7243081B2 (en) * 1995-10-30 2007-07-10 Efi Actuaries Method of determining optimal asset allocation utilizing asset cash flow simulation
US5963922A (en) * 1996-02-29 1999-10-05 Helmering; Paul F. System for graphically mapping related elements of a plurality of transactions
US5897621A (en) * 1996-06-14 1999-04-27 Cybercash, Inc. System and method for multi-currency transactions
US5878405A (en) * 1996-09-25 1999-03-02 Coordinated Data Services, Inc. Pension planning and liquidity management system
US6009402A (en) * 1997-07-28 1999-12-28 Whitworth; Brian L. System and method for predicting, comparing and presenting the cost of self insurance versus insurance and for creating bond financing when advantageous
US5978780A (en) * 1997-11-21 1999-11-02 Craig Michael Watson Integrated bill consolidation, payment aggregation, and settlement system
US6122623A (en) * 1998-07-02 2000-09-19 Financial Engineering Associates, Inc. Watershed method for controlling cashflow mapping in value at risk determination
JP4240588B2 (ja) * 1998-07-07 2009-03-18 株式会社日立製作所 リスク算出方法および装置ならびにリスク算出プログラムを格納した記憶媒体
US6513019B2 (en) * 1999-02-16 2003-01-28 Financial Technologies International, Inc. Financial consolidation and communication platform
US7117172B1 (en) * 1999-03-11 2006-10-03 Corecard Software, Inc. Methods and systems for managing financial accounts
US20010056391A1 (en) * 2000-01-14 2001-12-27 Schultz Frederick J. Method and apparatus for managing and optimizing stock options
US20060020530A1 (en) * 2000-02-14 2006-01-26 Hsu Phillip K Systems for providing financial services
US7006992B1 (en) * 2000-04-06 2006-02-28 Union State Bank Risk assessment and management system
GB2379064A (en) * 2000-04-14 2003-02-26 Vantage Internat Inc E Method and system for delivering foreign exchange risk management advisory solutions to a designated market
US7349875B1 (en) * 2000-06-29 2008-03-25 Ncr Corp. Basic and intermediate net interest revenue implementations for financial processing in a relational database management system
US7146337B1 (en) * 2000-09-13 2006-12-05 Precept Corporation System and method for originating loans
US20020184141A1 (en) * 2000-10-26 2002-12-05 Jeremy Stein System and method for estimating cash flow at risk for a non-financial institution
US20020123949A1 (en) * 2000-12-15 2002-09-05 Vanleeuwen Michael J. System and method for financial management and analysis
US20110131079A1 (en) * 2000-12-20 2011-06-02 Suzanne Valentine System and Method for Modeling by Customer Segments
US20030018548A1 (en) * 2001-02-07 2003-01-23 Danilo Cattaneo System for economic-financial planning
JP4701510B2 (ja) * 2001-02-09 2011-06-15 ソニー株式会社 金融取引に関する取引情報を集約する装置、及びその方法
US7398236B2 (en) * 2001-04-30 2008-07-08 Max Jaffe Method and medium for budgeting
US7555451B2 (en) * 2001-05-17 2009-06-30 Microsoft Corporation Cash flow forecasting
US8260699B2 (en) * 2001-05-30 2012-09-04 Finicity Corp. Method and system for managing spending through account allocation

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH05225222A (ja) * 1992-02-10 1993-09-03 Hitachi Ltd 資金シフトシミュレーションシステム
JPH1186089A (ja) * 1997-09-03 1999-03-30 Fujitsu Ltd 在高管理システム
JPH11175602A (ja) * 1997-12-12 1999-07-02 Fujitsu Ltd 信用リスク計測装置
JPH11296610A (ja) * 1998-04-10 1999-10-29 Bank Of Tokyo Mitsubishi Ltd 資金管理システム

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
"Facom unios kyotsu capsel III system kaisetsusho zaimu kaikei system", 31 January 1985, FUJITSU LTD., XP002909324 *
See also references of EP1359525A4 *
ZAIKEI SHOHOSHA K.K.: "Kin'yu joho system hakusho (heisei 13 nenban)", THE CENTER FOR FINANCIAL INDUSTRY INFORMATION SYSTEMS, 1 December 2000 (2000-12-01), pages 526, XP002909323 *

Also Published As

Publication number Publication date
EP1359525A4 (en) 2006-05-31
US20140114821A1 (en) 2014-04-24
EP1359525A1 (en) 2003-11-05
CN1460219A (zh) 2003-12-03
JP4701510B2 (ja) 2011-06-15
US20030163398A1 (en) 2003-08-28
JP2002236800A (ja) 2002-08-23

Similar Documents

Publication Publication Date Title
JP4701510B2 (ja) 金融取引に関する取引情報を集約する装置、及びその方法
US6216115B1 (en) Method for multi-directional consumer purchasing, selling, and transaction management
US8170936B2 (en) Method and system for emulating a private label over an open network
US8065187B2 (en) System, program product, and associated methods to autodraw for micro-credit attached to a prepaid card
US8341021B2 (en) System, program product, and method for debit card and checking account autodraw
US8131619B1 (en) Service fee-based payment processing
US7379912B1 (en) System and method for processing loan information
US20070185810A1 (en) System, method, and computer program product for saving and investing through use of transaction cards
CN101595506A (zh) 限制多方交易中的对方风险
WO2009021045A1 (en) System and method for repaying an obligation
US20200219189A1 (en) JYB-based Barter Transaction Platform
WO2019018713A1 (en) LOAN SYSTEMS AND METHODS BETWEEN INDIVIDUALS BASED ON DISTRIBUTED REGISTER
Khiaonarong et al. Instant Payments: Regulatory Innovation and Payment Substitution Across Countries
Herbst-Murphy Clearing and settlement of interbank card transactions: A mastercard tutorial for federal reserve payments analysts
JP2000268119A (ja) 債権消込処理システム及び債権消込処理方法
JP2002175395A (ja) 経理処理システム、経理処理方法及びこれを実行するためのプログラムを記録した媒体
US20140006192A1 (en) Selective escrow of funds based on transaction receipts
JPH08255203A (ja) 資金繰予定シミュレーションシステム
AU2016100977A4 (en) Method and system for automated collection and rebate of a gst taxation
TWI343548B (en) Method and apparatus for automatically transferring interest into investment by use of debit service client
JP2004038614A (ja) 入出金代行処理方法、コンピュータ・プログラム及び記録媒体
Kadam STUDY OF FINANCIAL OF SERVICES PROVIDED BY COMMERCIAL BANKS
JP2006039649A (ja) 投資信託販売システムおよびコンピュータプログラム
CN117011076A (zh) 一种智能记账系统
CN117057909A (zh) 分销商应收账款质押下的银行融资定价决策系统及方法

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A1

Designated state(s): AE AG AL AM AT AU AZ BA BB BG BR BY BZ CA CH CN CO CR CU CZ DE DK DM DZ EC EE ES FI GB GD GE GH GM HR HU ID IL IN IS KE KG KP KR KZ LC LK LR LS LT LU LV MA MD MG MK MN MW MX MZ NO NZ OM PH PL PT RO RU SD SE SG SI SK SL TJ TM TN TR TT TZ UA UG US UZ VN YU ZA ZM ZW

AL Designated countries for regional patents

Kind code of ref document: A1

Designated state(s): GH GM KE LS MW MZ SD SL SZ TZ UG ZM ZW AM AZ BY KG KZ MD RU TJ TM AT BE CH CY DE DK ES FI FR GB GR IE IT LU MC NL PT SE TR BF BJ CF CG CI CM GA GN GQ GW ML MR NE SN TD TG

WWE Wipo information: entry into national phase

Ref document number: 2002711339

Country of ref document: EP

121 Ep: the epo has been informed by wipo that ep was designated in this application
WWE Wipo information: entry into national phase

Ref document number: 028007824

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 10240967

Country of ref document: US

WWP Wipo information: published in national office

Ref document number: 2002711339

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWW Wipo information: withdrawn in national office

Ref document number: 2002711339

Country of ref document: EP