JP2018045279A - Transaction proposal system, transaction proposal method, and transaction proposal program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a transaction proposal system, a transaction proposal method, and a transaction proposal program for proposing appropriate transactions to users on the basis of their account balance.SOLUTION: A management server 20 includes: a proposal information storage unit 23 for storing proposal contents and proposal output conditions to users; account information storage unit 25 for storing an account balance by the account of a user; a withdrawal schedule information storage unit 27 for storing withdrawal schedule information about the account; and a control unit 21 connected to a user terminal 10. The control unit 21 calculates a predicted balance of the user on a withdrawal scheduled date on the basis of the withdrawal schedule information stored in the withdrawal schedule information storage unit 27, compares the predicted balance with the proposal output conditions stored in the proposal information storage unit 23 to determine a proposal to the user, determines conditions corresponding to a transaction period until the withdrawal scheduled date regarding the proposal, and outputs them to the user terminal 10.SELECTED DRAWING: Figure 1

Description

  The present invention relates to a transaction proposal system, a transaction proposal method, and a transaction proposal program for proposing a transaction to a user based on an account balance.

  Today, various payments are often made using a deposit account. These payments include usage fees for telephone, electricity, gas, water, etc., loan repayment, credit card usage fees, and the like. In this case, these payments may be made using a deposit account automatic transfer service provided by a financial institution. Since the account balance fluctuates due to such withdrawal, an account information providing method for providing information related to the account balance to the user has been studied (for example, see Patent Document 1). In the technique described in this document, the management computer calculates a scheduled deposit / withdrawal amount for a desired prediction period using the deposit / withdrawal prediction function recorded in the deposit / withdrawal prediction data storage unit. When the deposit / withdrawal prediction function depends on the deposit / withdrawal history, the management computer specifies the deposit / withdrawal history using the keyword included in the summary. Then, a predicted balance is calculated from the scheduled deposit / withdrawal amount and the current balance. When the predicted balance exceeds the upper limit balance recorded in the notification condition data storage unit, the management computer notifies the user. On the other hand, if the predicted balance causes a shortage relative to the lower limit balance, it is confirmed whether there is an account that can compensate for the shortage. If there is an account that can be compensated, a notification including a transfer proposal from this account to the account that has generated a shortage is made.

JP 2003-323547 A

  In the technique described in the above document, it is possible to notify the user of a surplus balance or a shortage of balance. In addition, even when a shortage of balance occurs, the user does not always have an account that can compensate for the shortage. In this case, it is necessary to make a deposit to an account that causes a shortage, which is troublesome. On the other hand, even when there is a surplus of balance, it is difficult to effectively utilize the balance unless a transaction can be proposed at an appropriate timing based on the balance prediction.

  The present invention has been made to solve the above problems, and provides a transaction proposal system, a transaction proposal method, and a transaction proposal program for proposing an accurate transaction to a user based on an account balance. There is to do.

  The transaction proposal system that solves the above problems includes an account information storage unit that stores an account balance for each user account, a withdrawal schedule information storage unit that stores withdrawal schedule information for the account, and a proposal content for the user And a proposal information storage unit for storing the proposal output conditions, and a control unit connected to the user terminal. Based on the withdrawal schedule information stored in the withdrawal schedule information storage unit, the control unit calculates a predicted balance of the user on the scheduled withdrawal date, and the proposal output stored in the forecast balance and the proposal information storage unit Compared with conditions, a proposal for the user is specified, a condition corresponding to the transaction time until the withdrawal date is determined for the proposal, and the condition is output to the user terminal of the user. Thereby, a transaction can be proposed based on the account balance on the scheduled withdrawal date. Furthermore, an early transaction can be promoted by changing the transaction conditions according to the time of the proposed transaction.

  In the transaction proposal system, the control unit specifies a proposal for a transaction using a balance when there is a surplus in the predicted balance, and supplements the balance when there is a shortage in the predicted balance. It is preferable to identify proposals for transactions. Thereby, the surplus balance can be utilized and the balance shortage can be supported according to the account balance prediction.

  -In the above-mentioned transaction proposal system, it is preferred that the control part transmits the proposal to the user terminal by push type notification and outputs it. This makes it possible to make a proposal in a timely manner.

  -In the above-mentioned transaction proposal system, it is preferred that the control part determines the transmission timing of the push type notification according to the contents of the proposal. Thereby, a proposal can be made in consideration of a user's situation.

  -In the above-mentioned transaction proposal system, it is preferred that the control part adjusts the proposal to a transaction condition advantageous to the user according to the transaction history of the user. Thereby, an accurate proposal can be performed in consideration of a user's transaction history.

  According to the present invention, it is possible to propose an accurate transaction to the user based on the account balance.

Explanatory drawing of the transaction proposal system of this embodiment. It is explanatory drawing of the information storage part of this embodiment, (a) is a store information storage part, (b) is a proposal information storage part, (c) is a customer information storage part, (d) is an account information storage part, (E) is a transaction information storage part, (f) is explanatory drawing of a withdrawal plan information storage part. Explanatory drawing of the process sequence of this embodiment. Explanatory drawing of the process sequence of other embodiment.

  Hereinafter, according to FIGS. 1-3, one Embodiment which actualized the transaction proposal system, the transaction proposal method, and the transaction proposal program is described. In the present embodiment, it is assumed that a transaction proposal according to the account balance is made to a customer (user) of a financial institution.

Here, as shown in FIG. 1, a user terminal 10, a management server 20, and a storage company server 30 connected via a network are used.
The user terminal 10 is a computer terminal used by a customer who has opened an account with a financial institution. The user terminal 10 is connected to the management server 20 via a network. The user terminal 10 includes a control unit 11, a touch panel display 12, and a position information acquisition unit 13. The control unit 11 executes various applications and outputs data (such as a web page) acquired from the management server 20 to the touch panel display 12. The touch panel display 12 functions as an output unit that outputs information on a screen and an input unit that inputs information by a touch operation or the like. The position information acquisition unit 13 acquires the location information of the user terminal 10 by using, for example, a GPS (Global Positioning System) function. The method for acquiring the location information is not limited to the use of the GPS function, and any method that can identify the access location may be used. For example, it is possible to use network address information (source IP address) used for access.

  The user terminal 10 stores an application provided from a financial institution. This application uses push notifications. This push-type notification is a notification obtained by an operating system (OS) management server (not shown) from the management server 20 of the financial institution based on the permission at the time of application installation or the like. The notification is transferred to the OS and displayed on the screen of the user terminal 10 or in the application.

  The management server 20 is a computer system that manages transactions with customers in financial institutions. The management server 20 includes a control unit 21, a store information storage unit 22, a proposal information storage unit 23, a customer information storage unit 24, an account information storage unit 25, a transaction information storage unit 26, and a withdrawal schedule information storage unit 27. .

  As shown in FIG. 2A, the store information storage unit 22 stores a store management record 220 relating to a store of a financial institution. The store management record 220 is recorded when a store is registered. In the store management record 220, data related to the store ID, contact information, address, and business hours are recorded.

Data relating to an identifier for identifying each store is recorded in the store ID data area.
In the contact information, address, and business hours data areas, data related to the store contact information (telephone number, etc.), address, and business hours are recorded.

  As shown in FIG. 2B, the proposal information storage unit 23 records a proposal management record 230 related to a proposal for a customer. The proposal management record 230 is recorded when a proposal is registered. In the proposal management record 230, data relating to a proposal code, contents, proposal output conditions, transaction conditions, and transaction time conditions are recorded.

Data relating to an identifier for specifying each proposal is recorded in the proposal code data area.
In the content data area, data relating to the content of the proposal is recorded. With regard to proposals for utilizing surplus balances, proposals such as transfers, transfers, yen fixed term, foreign currency fixed term, and investment trusts are recorded. On the other hand, proposals for opening a card loan account, borrowing, credit revolving payment, etc. are recorded for the support proposal for insufficient balance.

  In the proposal output condition data area, data relating to conditions for outputting the proposal is recorded. In the present embodiment, the balance range of the account is recorded as a condition for outputting the proposal. Further, customer attributes and transaction history (transaction type and number of transactions) may be included in the proposal output conditions.

  In the transaction condition data area, data relating to conditions for trading the proposed product is recorded. For example, for the first time, a condition for trading this product and a condition for re-trading the same product (for example, an advantageous interest rate) are set.

  In the transaction time condition data area, data relating to the conditions corresponding to the time when the proposed product is traded is recorded. For example, conditions that are advantageous when the transaction time (transaction timing) is earlier are set.

  As shown in FIG. 2C, the customer information storage unit 24 stores a customer management record 240 for customers of financial institutions. The customer management record 240 is recorded when a customer opens an account with a financial institution. In the customer management record 240, data related to customer code, name, account identifier, contact information, address, and customer attributes are recorded.

In the customer code data area, data relating to an identifier for identifying each customer of the financial institution is recorded.
In the name data area, data related to the customer's name is recorded.
In the account identifier data area, data relating to an identifier (main branch code, type code, account number) for specifying an account held by the customer is recorded.

  In the contact data area, data related to the customer's contact information is recorded. This contact information is used as information for specifying a device (user terminal 10) that outputs a proposal by push notification.

In the address data area, data related to the customer's address is recorded.
In the customer attribute data area, data relating to the customer attributes (age, gender, job type, etc.) is recorded.

  As shown in FIG. 2D, an account management record 250 for managing transactions using an account opened by a customer is recorded in the account information storage unit 25. The account management record 250 is registered when an account is opened in a financial institution. In this account management record 250, data relating to an account identifier, an account balance, and an account history is recorded.

Data relating to an identifier for identifying each account is recorded in the account identifier data area.
Data relating to the balance of this account is recorded in the account balance data area.
In the account history data area, data related to the date and time of deposit / withdrawal, the amount of money, a summary, etc. are recorded for the deposit and withdrawal in this account.

  As shown in FIG. 2E, a transaction management record 260 for managing transactions with customers is recorded in the transaction information storage unit 26. The transaction management record 260 is registered when an account is opened in a financial institution. In this transaction management record 260, data relating to a customer code and transaction history is recorded.

Data relating to an identifier for identifying each customer is recorded in the customer code data area.
In the transaction history data area, data related to the transaction date and time, transaction type, transaction amount, and transaction place is recorded for the transaction performed with the customer. For the transaction type, an identifier for specifying the financial product purchased at this financial institution is recorded. For the transaction place, an identifier for identifying the store where the transaction was performed is recorded.

  As shown in FIG. 2 (f), the withdrawal schedule information storage unit 27 records a withdrawal schedule management record 270 related to a withdrawal schedule that is withdrawn from a customer account. The withdrawal schedule management record 270 is registered when withdrawal schedule information is obtained from the storage organization. In this withdrawal schedule management record 270, data relating to the storage company, the withdrawal scheduled date, the withdrawal account, and the withdrawal amount is recorded.

In the storage company data area, data relating to an identifier for specifying a storage company to be debited from a customer account is recorded.
In the scheduled withdrawal date data area, data relating to the scheduled date of withdrawal is recorded.
In the withdrawal account data area, data relating to an identifier for identifying an account to be withdrawn is recorded.
In the withdrawal amount data area, data relating to the amount to be withdrawn is recorded.

The control unit 21 shown in FIG. 1 includes control means (CPU, RAM, ROM, etc.), and performs processes (each process such as an information acquisition stage, a balance prediction stage, and a proposal stage) described later. The control part 21 functions as the information acquisition part 211, the balance prediction part 212, and the proposal part 213 by executing the transaction proposal program for it.
The information acquisition unit 211 executes processing for acquiring withdrawal schedule information from the customer's account from the storage company server 30 and registering it in the withdrawal schedule information storage unit 27.
The balance prediction unit 212 executes processing for predicting the account balance on the scheduled withdrawal date.
The proposing unit 213 executes a process for proposing a transaction based on the predicted account balance.

  The storage company server 30 is a storage company computer system that provides services to customers and deducts the charges from the customer's account. Examples of storage companies include credit card companies and utility bill storage companies. The storage company server 30 determines a billing amount corresponding to the use of the service for each customer, and withdraws the billing amount from each user's account using an automatic account transfer system.

(Proposal processing)
Next, the procedure of the proposal process in this transaction proposal system will be described using FIG.
First, the control unit 21 of the management server 20 executes a withdrawal schedule information acquisition process (step S1-1). Specifically, the information acquisition unit 211 of the control unit 21 acquires withdrawal schedule information (for example, payment using a credit card) from the storage company server 30. Then, the information acquisition unit 211 generates a withdrawal schedule management record 270 based on the acquired withdrawal schedule information and records it in the withdrawal schedule information storage unit 27.

Next, the control unit 21 of the management server 20 specifies a processing target account in the withdrawal account recorded in the withdrawal schedule management record 270 and repeats the following processing.
Here, the control unit 21 of the management server 20 executes a process for predicting the deposit / withdrawal amount until the scheduled withdrawal date (step S1-2). Specifically, the balance prediction unit 212 of the control unit 21 specifies the account management record 250 of the processing target account for a predetermined evaluation target period (for example, half a year). Then, the balance prediction unit 212 specifies a deposit / withdrawal history that is regularly performed using the summary in the account management record 250. As the periodic deposit / withdrawal history, for example, the withdrawal of salary or utility charges is specified. Next, the balance prediction unit 212 predicts a deposit / withdrawal date based on a periodic deposit / withdrawal history, and predicts a deposit / withdrawal that may be performed by the scheduled date of the withdrawal schedule management record 270. Then, the balance prediction unit 212 calculates the statistical amount of deposit and withdrawal during the evaluation target period. As the statistical amount, for example, an average value can be used. Note that the minimum amount of deposit and the maximum amount of withdrawal may be used as the statistical amount. Further, when another withdrawal schedule management record 270 withdrawn before the withdrawal scheduled date is recorded for the processing target account and is not included in the periodic deposit / withdrawal history, the balance prediction unit 212 determines the withdrawal amount. Is deducted from the account balance.

  Next, the control part 21 of the management server 20 performs the prediction process of the balance of a scheduled withdrawal date (step S1-3). Specifically, the balance prediction unit 212 of the control unit 21 acquires the current account balance of the processing target account from the account management record 250 of the account information storage unit 25. Then, the balance prediction unit 212 calculates the predicted balance on the scheduled withdrawal date by subtracting the withdrawal amount from the current account balance, adding the statistical amount for deposit prediction, and subtracting the statistical amount for withdrawal prediction.

  Next, the control unit 21 of the management server 20 performs a determination process as to whether or not the predicted balance is equal to or less than a reference value (step S1-4). Specifically, the balance prediction unit 212 of the control unit 21 compares the predicted balance with a reference value (here, “0”).

  When it is determined that the predicted balance is higher than the reference value (in the case of “NO” in step S1-4), the control unit 21 of the management server 20 executes a process for identifying the surplus balance utilization proposal (step S1-5). . Specifically, the suggestion unit 213 of the control unit 21 extracts the proposal management record 230 for the utilization proposal of the surplus balance from the proposal information storage unit 23. And the proposal part 213 acquires the customer code of a process target account using the customer information storage part 24, and acquires the transaction management record 260 in which this customer code was recorded from the transaction information storage part 26. FIG. Next, the proposal unit 213 compares the transaction history recorded in the transaction management record 260 with the proposal output conditions recorded in the proposal management record 230. Then, the proposal unit 213 extracts a proposal management record 230 whose transaction history matches the proposal output condition, and determines a proposal candidate. In this case, the proposal unit 213 adjusts the transaction conditions of the proposal candidates based on the transaction conditions recorded in the proposal management record 230 and the transaction history recorded in the transaction information storage unit 26. For example, when there is a history of transactions based on proposals in the past, the transaction conditions are changed to be better than those of past proposals according to the number of transactions.

  Next, the control part 21 of the management server 20 performs the calculation process of the conditions according to the transaction time of utilization proposal (step S1-6). Specifically, the proposal unit 213 of the control unit 21 adjusts the transaction conditions for the period up to the scheduled withdrawal date for the proposal candidates based on the transaction timing conditions recorded in the proposal management record 230. Here, as a candidate for proposal, for example, when using financial products such as yen fixed term, foreign currency fixed term, investment trust, etc., the transaction conditions are set so that the current date is more advantageous (high interest rate) than the scheduled withdrawal date. decide.

  On the other hand, when it is determined that the predicted balance is equal to or less than the reference value (in the case of “YES” in step S1-4), the control unit 21 of the management server 20 executes a support shortage support proposal specifying process (step S1-7). ). Specifically, the proposal unit 213 of the control unit 21 extracts the proposal management record 230 for the support proposal with insufficient balance from the proposal information storage unit 23. Then, similarly to step S1-5, the proposal unit 213 acquires the transaction management record 260, compares it with the proposal output condition, determines a proposal candidate, and adjusts the transaction condition.

  Next, the control part 21 of the management server 20 performs the calculation process of the conditions according to the transaction time of a support proposal (step S1-8). Specifically, the proposal unit 213 of the control unit 21 adjusts the transaction conditions for the period up to the scheduled withdrawal date for the proposal candidates based on the transaction timing conditions recorded in the proposal management record 230. Here, when using a financial product such as opening a card loan account or borrowing as a proposal candidate, the transaction condition is specified so that the condition closer to the current date (the lower interest rate) is more advantageous than the scheduled withdrawal date.

  Next, the control part 21 of the management server 20 performs the output process of proposal information (step S1-9). Specifically, the proposal unit 213 of the control unit 21 acquires the contact information recorded in the customer management record 240 and performs a message transmission process including the proposal content and transaction conditions. In this case, the user terminal 10 outputs the proposal contents and the transaction conditions by push-type notification.

As described above, according to the present embodiment, the following effects can be obtained.
(1) In the present embodiment, the control unit 21 of the management server 20 executes withdrawal schedule information acquisition processing (step S1-1) and balance withdrawal date balance prediction processing (step S1-3). Next, the control unit 21 of the management server 20 executes a surplus balance utilization proposal identifying process (step S1-5) or a shortage support proposal identifying process (step S1-7) according to the predicted balance. Then, the proposal information output process is executed (step S1-9). As a result, an accurate proposal can be made based on the balance prediction.

  (2) In this embodiment, the control part 21 of the management server 20 performs the prediction process of the deposit / withdrawal amount until the scheduled withdrawal date, and the forecast process of the balance of the scheduled withdrawal date (steps S1-2 and S1-3). Thereby, the account balance of the scheduled withdrawal date can be predicted in consideration of the deposit / withdrawal situation of the customer.

  (3) In this embodiment, the control unit 21 of the management server 20 executes a condition calculation process according to the transaction period of the surplus balance utilization proposal and the balance shortage support proposal (steps S1-6, S1-8). ). Thereby, an early transaction can be urged to the customer.

In addition, you may change the said embodiment into the following aspects.
In the above embodiment, the control unit 21 of the management server 20 executes the proposal information output process (step S1-9). Here, you may make it consider the place which proposes. In this case, the proposal is made in consideration of the transaction history and location of the customer. In this case, information relating to the necessity of product description is recorded in the transaction conditions of the proposal management record 230 of the proposal information storage unit 23. For example, when this product description is necessary, “at the first transaction”, “every time”, etc. are recorded.

The proposal process will be described with reference to FIG.
(Proposal processing)
First, the control part 21 of the management server 20 performs the specific process of the proposal with respect to a customer (step S2-1). Specifically, the proposal unit 213 of the control unit 21 specifies a proposal for the customer based on the proposal output condition and the account balance recorded in the proposal information storage unit 23.

  Next, the control part 21 of the management server 20 performs the determination process about whether description is required (step S2-2). Specifically, the proposal unit 213 of the control unit 21 uses the proposal management record 230 recorded in the proposal information storage unit 23 to determine whether the product description is necessary. Here, when the product description is necessary at the time of “first transaction”, the proposal unit 213 confirms the transaction history of the proposed product using the transaction management record 260 for this customer. If there is no transaction history for this product and this product is traded for the first time, it is determined that explanation is necessary. In addition, when the product description is necessary “every time”, the proposing unit 213 always determines that the description is necessary. On the other hand, if a product description is necessary at the time of “first transaction” and there is a transaction history, it is determined that the description is not necessary.

  When it is determined that the explanation is unnecessary (in the case of “NO” in Step S2-2), the control unit 21 of the management server 20 executes the output process of the proposal information (Step S2-3). Specifically, the proposal unit 213 of the control unit 21 outputs proposal information to the user terminal 10 by push notification.

  On the other hand, when it is determined that explanation is necessary (in the case of “YES” in step S2-2), the control unit 21 of the management server 20 executes a user location specifying process (step S2-4). Specifically, the suggestion unit 213 of the control unit 21 acquires location information from the position information acquisition unit 13 of the user terminal 10.

  Next, the control unit 21 of the management server 20 executes a determination process as to whether or not there is an open store within a predetermined range (step S2-5). Specifically, the suggestion unit 213 of the control unit 21 determines from the location by comparing the location information of the user terminal 10 with the address recorded in the store information storage unit 22 and the current time and business hours. Check if there are any open stores within the range.

  When it is determined that there is no open store within the predetermined range (in the case of “NO” in step S2-5), the control unit 21 of the management server 20 periodically performs the user location identification process (step S2-4). Repeat.

  On the other hand, when it is determined that there is a store in operation within the predetermined range (in the case of “YES” in step S2-5), the control unit 21 of the management server 20 executes a process for outputting proposal information (step S2- 6). Specifically, the proposal unit 213 of the control unit 21 outputs proposal information to the user terminal 10 by push notification. Further, a message indicating that the item description can be received at the store within the predetermined range is output to the proposal information.

  Moreover, in the said embodiment, the control part 21 of the management server 20 is a user's location specific process (step S2-4), and the determination process (step S2-5) about whether there is a store in operation within a predetermined range. ). These processes may be executed by the application of the user terminal 10. In this case, as a proposal information output process (step S1-9), a message about financial institution store information or a proposal is provided to the application of the user terminal 10. Then, the control unit 11 of the user terminal 10 acquires the current location from the position information acquisition unit 13. And when the control part 11 detects the store of a financial institution within the predetermined range from the present location, the message about a proposal is output.

  In the above embodiment, the proposal is made in consideration of the usage history and the product transaction time. Here, when the same proposal has been made in the past, the transaction conditions may be changed. In this case, the transaction management record 260 of the transaction information storage unit 26 records the presence / absence of the transaction based on the proposal.

  And when making the proposal based on an account balance with respect to a user, the transaction management record 260 about the proposal goods in this customer is specified. Here, when there is a transaction history based on the same proposal in the past, the control unit 21 of the management server 20 changes the transaction condition. For example, a procedure necessary for a transaction based on a proposal is omitted. Here, the procedure includes input of a confirmation password required at the time of transaction. Thereby, utilization of a proposal goods can be simplified.

In the above embodiment, the control unit 21 of the management server 20 executes the proposal information output process (step S1-9). In this case, a message including the proposal contents and transaction conditions is output by push-type notification. The method for outputting the proposal information is not limited to push notification. For example, the touch panel display 12 of the user terminal 10 may be popped up. In addition, when there is a material that is difficult to read by push-type notification or the like, link information to be displayed in the proposal content may be included. In the link information, an identification code (for example, a customer code or a proposal code) for specifying a customer or a proposal is added to the URL as a parameter. By using this URL, it is possible to confirm browsing of the investment trust prospectus, the card loan product manual, and the like.
Further, in addition to the push-type notification, it may be transmitted to a mail address designated by the customer. In this case, the mail address is recorded in the contact address of the customer management record 240.

  In the above embodiment, the control unit 21 of the management server 20 executes the proposal information output process (step S1-9). Here, the transmission timing of the push-type notification may be changed between a case where a surplus balance utilization proposal is made and a case where a balance shortage support proposal is made. In this case, the output timing (output possible time zone) of the push notification is registered as the proposal output condition of the proposal management record 230 in the proposal information storage unit 23. For example, in the case of making a support proposal for a shortage of balance, a push-type notification is made when a shortage of balance is detected (from 0:00 to 24:00). On the other hand, when the utilization proposal of the surplus balance is made, it is output in a predetermined time zone (for example, 12:00 to 13:00, 18:00 to 21:00, etc.). Thereby, the shortage of the remaining amount can be notified promptly, and the surplus balance can be notified to the customer in a time zone that is expected to be relatively free.

  In the above embodiment, when it is determined that the predicted balance is higher than the reference value (here, “0”) (in the case of “NO” in step S1-4), the control unit 21 of the management server 20 uses the surplus balance. Proposed specific processing is executed (step S1-5). The reference value is not limited to “0”. For example, a reference value related to a shortage of balance and a reference value related to a surplus balance may be provided separately. For example, the reference value regarding the shortage of balance may be “0”, and the reference value regarding the surplus balance may be “100,000 yen”. Furthermore, the reference value regarding the surplus balance may be set based on the statistical value of each account. In this case, for example, the control unit 21 of the management server 20 may calculate the average balance of the account and use the average balance as a reference value to make a use proposal of the surplus balance.

  DESCRIPTION OF SYMBOLS 10 ... User terminal, 20 ... Management server, 21 ... Control part, 211 ... Information acquisition part, 212 ... Balance prediction part, 213 ... Proposal part, 22 ... Store information storage part, 23 ... Proposal information storage part, 24 ... Customer Information storage unit, 25 ... Account information storage unit, 26 ... Transaction information storage unit, 27 ... Withdrawal schedule information storage unit.

Claims (7)

An account information storage unit for storing an account balance for each user account;
A withdrawal schedule information storage unit for storing withdrawal schedule information for the account;
A proposal information storage unit for storing proposal contents and proposal output conditions for users;
A transaction proposal system including a control unit connected to a user terminal,
The control unit is
Based on the withdrawal schedule information stored in the withdrawal schedule information storage unit, the predicted balance of the user on the scheduled withdrawal date is calculated,
Compare the predicted balance with the proposal output condition stored in the proposal information storage unit, identify a proposal for the user,
About the said proposal, the conditions according to the transaction time until a withdrawal date are determined, and the transaction proposal system characterized by outputting to the user terminal of the said user.   The control unit specifies a proposal for a transaction that uses a balance when there is a surplus in the predicted balance, and specifies a proposal for a transaction that supplements the balance when the predicted balance has a shortage of balance. The transaction proposal system according to claim 1, wherein:   3. The transaction proposal system according to claim 1, wherein the control unit transmits the proposal to the user terminal by push notification and outputs the proposal. 4.   4. The transaction proposal system according to claim 3, wherein the control unit determines a transmission timing of the push notification according to the proposal content.   5. The transaction proposal system according to claim 1, wherein the control unit adjusts the proposal to a transaction condition advantageous to a user according to the transaction history of the user. An account information storage unit for storing an account balance for each user account;
A withdrawal schedule information storage unit for storing withdrawal schedule information for the account;
A proposal information storage unit for storing proposal contents and proposal output conditions for users;
A transaction proposal system using a transaction proposal system including a control unit connected to a user terminal,
The control unit is
Based on the withdrawal schedule information stored in the withdrawal schedule information storage unit, the predicted balance of the user on the scheduled withdrawal date is calculated,
Compare the predicted balance with the proposal output condition stored in the proposal information storage unit, identify a proposal for the user,
About the said proposal, the condition according to the transaction time until a withdrawal date is determined, The transaction proposal method characterized by outputting to the said user's user terminal. An account information storage unit for storing an account balance for each user account;
A withdrawal schedule information storage unit for storing withdrawal schedule information for the account;
A proposal information storage unit for storing proposal contents and proposal output conditions for users;
A program for making a transaction proposal using a transaction proposal system including a control unit connected to a user terminal,
The control unit
Based on the withdrawal schedule information stored in the withdrawal schedule information storage unit, the predicted balance of the user on the scheduled withdrawal date is calculated,
Compare the predicted balance with the proposal output condition stored in the proposal information storage unit, identify a proposal for the user,
About the said proposal, the conditions according to the transaction time until a withdrawal date are determined, and it is made to function as a means to output to the said user's user terminal, The transaction proposal program characterized by the above-mentioned.

Images