Real-time method of adaptive-granularity interest calculation

Abstract

A method performed by a financial system of calculating interest during a financial transaction is provided. The method includes, during a financial transaction for an account involving a balance change, (i) reading account information for the account, (ii) tracking an interest amount associated with the account based on the balance change, and (iii) writing updated account information for the account. The method includes, at the end of a current interest period, calculating an interest for the account using the tracked interest amount.

Description

REAL-TIME METHOD OF ADAPTIVE-GRANULARITY INTEREST CALCULATIONTECHNICAL FIELD

[0001] Disclosed are embodiments related to a real-time method of adaptive-granularity interest calculation.BACKGROUND

[0002] Banks and financial systems that offer savings accounts with interest need to base the interest to be paid out on the average balance that the customer (or account holder) has had on the account during the interest paying period. Similar consideration also applies to banks and financial systems that offer loan accounts having an interest rate associated with payment of the loan.

[0003] The existing solutions are based on scheduled jobs or procedures that run daily (e.g., right after midnight) and loop through all interest-bearing accounts. These scheduled jobs or procedures run for each account regardless of if there has been any activity on the account or not. They save the balance for each account in one row for each day, to allow for a future average balance calculation as input for a later interest calculation.

[0004] FIG. 1 illustrates average balance jobs running daily. The circles represent balance updates (balance changes) on the account and the crosses represent the balance jobs that runs every night, performing calculations and storing the results. In this example, seven calculations and database updates were made (one each night, from 2 / 4 through 8 / 4), just to keep track of daily average for a 7-day period. In particular, the balance jobs are run even if the balance was not updated every day.SUMMARY

[0005] The existing approach has numerous issues.

[0006] Currently, the balance used for interest calculation is saved on a daily basis. This is to ensure that the scheduled job has been executed properly for each day of the period. This requires one row per day, for each account that is interest bearing, regardless of if there have been any changes to the account or not.

[0007] The existing solutions require a daily job to read up, calculate and store the daily end of day balance for each account (end-of-day job). The end of day job runs regardless of any activity on the account, which means that accounts that were not touched at all during the period will still have one row per day in the interest period in the database.

[0008] The daily processing of the end-of-day balances requires extra physical storage, CPU utilization and network communication. As an example, a system with 9 million interest bearing accounts requires fetching, calculating, and storing the balance information for each account every day, resulting in 270 million rows for an interest period of 30 days.

[0009] At interest payout calculation, more resources will be required due to the large amount of data to process for each account.

[0010] Other issues with the current approach include the following:

[0011] 1) In a system with a large number of accounts to be covered in the end-of-day balances, where the job is triggered some time during low peak hours, there might not be enough time to cover all accounts in a timeframe where the account balances remain unchanged.

[0012] 2) If the scheduling service is down or does not have time to complete (e.g., unavailable due to maintenance or similar) it could mean that the end-of-day balances could potentially lose precision.

[0013] 3) Not viable to get real time reports (e.g. interest debt report).

[0014] 4) If different banks are using various time schedules for the end-of- day balance(main office in different time zones for example) then there is a risk of fraud by movement of money between banks to earn interest in multiple banks. Even if the time is synced between banks, there is a risk of fraud as it takes time to go through all the accounts. To get an accurate end-of-day balance snapshot, some systems use a very resource-heavy extra calculation using the balance history — where the current balance minus any balance changes that happened between end of yesterday and now (after midnight) would need to be taken into consideration. To do so would require both more processing time and resources.

[0015] Embodiments provide a way of keeping an updated, fine granular average balance for a period, to be used as basis for interest calculations, or potentially other type of scenarios.

[0016] In embodiments, the storage of the average or accumulated balances is improved, since the balance may be accumulated for each slice (given the granularity) and it is enough to store the accumulated value in one entry, since the entry may also include a “last updated” timestamp. The last updated timestamp may be utilized to know if a catch up is required, as described herein. An accumulated balance calculation may be triggered by the transaction flow and may be done at a balance change on the account rather than during a loop through all accounts in a scheduled job. In embodiments, the extra cost for calculating the new total accumulated balance is negligible since all the data needed for the balance change is already being read and storage of the new accumulated balance total may also be negligible if stored using the same database transaction as the balance update. Another advantage with this approach, in some embodiments, is that the load of doing an accumulated balance calculation and storage is spread out over the day (rather than concentrated in a scheduled job looping through all accounts), since transactions resulting in balance updates can happen any time during the day.

[0017] The granularity of a slice may be configurable, and it doesn't cost more resources to have a finer precision since these calculations are done as part of other balance changes as explained earlier. Embodiments may also avoid fraud, since with more granularity, the balance average is only affected for the actual time the balance is on the account. As an example, scenarios where an account holder transfers a large amount to the account for a short period only (say 5 seconds) to earn interest for a full day are avoided if slice granularity is seconds.

[0018] According to a first aspect, a method performed by a financial system of calculating interest during a financial transaction is provided. The method includes, during a financial transaction for an account involving a balance change, (i) reading account information for the account, (ii) tracking an interest amount associated with the account based on the balance change, and (iii) writing updated account information for the account. The method includes, at the end of a current interest period, calculating an interest for the account using the tracked interest amount.

[0019] According to a second aspect, a financial system is provided. The financial system includes processing circuitry; and a memory, the memory containing instructions executable by the processing circuitry, whereby when executed the processing circuitry isconfigured to, during a financial transaction for an account involving a balance change, (i) read account information for the account, (ii) track an interest amount associated with the account based on the balance change, and (iii) write updated account information for the account. The processing circuitry is further configured to, at the end of a current interest period, calculate an interest for the account using the tracked interest amount.

[0020] According to a third aspect, a computer program is provided, comprising instructions which when executed by the processing circuitry of a node cause the node to perform the method of any of the embodiments of the first and second aspects.

[0021] According to a fourth aspect, a carrier is provided, containing the computer program of the third aspect. The carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium.BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The accompanying drawings, which are incorporated herein and form part of the specification, illustrate various embodiments.

[0023] FIG. 1 illustrates average balance jobs running daily.

[0024] FIG. 2 illustrates a number of balance changes and tracking calculations according to an embodiment.

[0025] FIG. 3 A illustrates daily scheduled jobs according to related art.

[0026] FIG. 3B illustrates a number of balance changes and tracking calculations according to an embodiment.

[0027] FIG. 4 illustrates a number of balance changes and tracking calculations according to an embodiment.

[0028] FIG. 5 illustrates a system according to an embodiment.

[0029] FIG. 6 illustrates a number of balance changes and tracking calculations according to an embodiment.

[0030] FIG. 7 illustrates a flowchart according to an embodiment.

[0031] FIG. 8 illustrates a flowchart according to an embodiment.

[0032] FIG. 9 illustrates a flowchart according to an embodiment.

[0033] FIG. 10 is a block diagram of an apparatus according to an embodiment.DETAILED DESCRIPTION

[0034] Calculating and storing the balance input for interest calculation

[0035] FIG. 2 illustrates a number of balance changes and tracking calculations according to an embodiment. It also provides a good overview of some of the terminology used herein. In embodiments, instead of looping through all accounts daily, the new accumulated balance may be calculated and stored only when the account balance is updated (i.e., there is a balance change) by other transactions handled by the financial system. The interaction with other transactions handled by the financial system is more fully explained later, in connection with FIG. 7.

[0036] Doing the balance updates and accumulated balance calculation only when a balance update is done gives many benefits. As the new accumulated balance used for average balance calculation may be stored together with the balance update, no additional resources are needed and the cost is negligible. Therefore, the granularity does not have to be daily, instead the average may be calculated based on any type of granularity (e.g., hour, minute, second) without extra cost. The storage of the data may also be optimized. That is, instead of storing one entry per day, embodiments can store an amount that represents the sum of all the slices up until this point in time in one entry.

[0037] The configuration shown in FIG. 2 involves a weekly interest payout period having a granularity of one hour. Accordingly, there are 24*7 = 168 slices in the period, in this example. Some of the slices are illustrated.

[0038] Granularity refers to how often an average balance is to be calculated, e.g., seconds, minutes, hours, days. Slice refers to a time period, defined by the granularity, e.g., one second, one minute, one hour, one day. Period (or interest payout period) refers to the period used for interest payout, e.g., weekly, monthly, yearly. Any configuration of period and granularity may be used in embodiments. In embodiments, there are at least two slices in a given interest payout period.

[0039] FIG. 3 A illustrates daily scheduled jobs according to related art. FIG. 3B illustrates a number of balance changes and tracking calculations according to an embodiment. A comparison of FIGS. 3 A and 3B illustrates the number of required updates to keep an average balance according to prior techniques compared to proposed embodiments.

[0040] As an example of the legacy approach, FIG. 3A shows a balance entry being stored for each day in the interest payout period per account. As an example of an embodiment, FIG. 3B shows a single balance entry being stored per account for the interest payout period. In the example, a last update date is recorded, along with the accumulated balance. As shown, in order to account for days when there was no balance change, the calculation multiplies the current balance by the number of slices since the last update (or the number of slices in the current interest payout period if there was no previous update in this period). As a result, the accumulated balance on 2024-04-05 is 200 + 100 + (100*1) + 110 = 510.

[0041] In embodiments, only one entry (in total) need be stored per account that has made a balance update, per period. In a real customer deployment, the accounts touched per month was less than 50% of the total number of account, with more than 50% of the account having no activity. Using the example above, having 9 million interest bearing accounts, instead of having 270 million entries, embodiments would only need to store 4.5 million entries.Moreover, because some embodiments do not require any extra database transaction, embodiments may also save 270 million database transactions per month. This is a significant technical improvement over the state of the art.

[0042] Interest calculation

[0043] In embodiments, the average balance to use as input for the interest payout calculation may be performed in two ways. For example, the average balance calculation may be performed immediately, when doing the calculation / storage at a balance change. Another approach is to store an accumulated balance, and perform the average balance calculation at the end of the interest payout period.

[0044] As an example of performing the average balance calculation immediately, assume that the granularity is daily, the interest payout period started four days ago, and thebalance on the account has been 100 for 3 days and then 10 more was added the fourth day.Given this, the average balance may be calculated as follows:100 + 100 + 100 + 110 = 440 / 4 = 102.5Accordingly, in this example, 102.5 is the persisted value when the average balance calculation is triggered by the balance change on day 5.

[0045] As an example of storing an accumulated balance, and performing the average balance calculation at the end of the interest payout period, assume that the granularity is daily, the interest payout period started four days ago, and the balance on the account has been 100 for 3 days and then 10 more was added the fourth day. Given this, the accumulated balance may be calculated as follows:100 + 100 + 100 + 110 = 440Accordingly, in this example, 440 is the persisted value when accumulated balance calculation is triggered by the balance change on day 5. At the end of the interest payout period, the total accumulated balance may be divided with the number of slices for the period, to arrive at the average balance.

[0046] While either of these approaches (immediately calculating the average, or storing the accumulated balance and calculating the average at the end of the interest payout period) may be used, for the sake of convenience the following examples and descriptions will focus on the second approach (storing the accumulated balance and calculating the average at the end of the interest payout period).

[0047] Embodiments provide for optimizing how the balance calculation and storage is done, e.g., by using account balance updates as a trigger and using the same database transaction to handle the average / accumulated balance update.

[0048] As embodiments may use slices, with a configurable granularity (e.g., day, hour, minute, etc.), the first transaction having a balance change that occurs in a slice will look at the current balance together with the last balance update date to calculate the new total value (e.g., the accumulated value for the period), filling in for slices that occurred in-between balance updates. Following transactions that occur within the same slice will skip the accumulated (oraverage) balance calculation and storage as the accumulation (or average) for the slices up to the previous slice has already been done.

[0049] This approach also allows for flexible granularity. A more fine-grained slice type will have a negligible effect on the resource utilization since calculation and storage is done as part of normal transactions (balance updates) which is already being handled by the financial system anyway.

[0050] By storing an accumulated (or average) balance for the interest payout period (including the slices that have passed so far), with a timestamp showing when the balance for the current period was last updated, it will be possible to do logic for catch-up of missed slices.Other logic may also be applied, and some use cases are shown below (e.g., interest prediction, flexible payouts, real-time interest calculations).

[0051] FIG. 4 illustrates that fine granularity slices can give a more precise average in some embodiments. In the example shown, the period is 6 days and 5 seconds. The account balance is 100 for the entire time, except for a credit of 999900 on the third day at 20240504 01:00:00 (to put the account balance at 100000) followed by a debit of 999900 at 20240504 01:00:05 (to put the account balance back at 100) five seconds later. Given a granularity of one second, and noting that 3 days = 24 hours / day * 60 minutes / hour * 60 seconds / hour = 259,200 seconds, the accumulated balance may be calculated as:100*259,200 + 1,000,000*5 + 100*259,200 = 56,840,000And the average balance per slice, over the 6 days and 5 seconds, may be computed as:56,840,000 / (259,200 +5 + 259,200) = 109.6(The average here is approximate to one decimal place of accuracy.)

[0052] In embodiments, an account with no balance changes during the interest payout period may do a catch-up calculation of accumulated (or average) balance in the interest calculation at the end of the interest payout period.

[0053] FIG. 5 illustrates a system according to an embodiment. As shown, system 500 includes a user 502 interacting with financial system 506, e.g., via an accessing service 504, such as a mobile application (or mobile app). Financial system 506 may include, for example, afirewall 508, a switch 510, and possibly other components associated with financial systems generally. The accessing service 504 interacts with an access layer 512 of the financial system 506, which in turn interacts with a financial system core 514 of the financial system 506. The access layer 512 handles access issues (e.g., security / authentication), while the financial system core 514 handles core financial issues (e.g., account transactions including balance changes). As part of handling core financial issues, financial system core 514 may interact with a database 516. According to some embodiments, financial system core 514 may also interact with an average balance calculator 518. The logic for implementing the accumulated balance or average balance calculations may be handled as part of average balance calculator 518. The diagram is schematic, and some or all of these functions may be implemented in the cloud.

[0054] When a financial transaction is handled, and after the required routing, authentication, and authorization logic is done, e.g., by the access layer 512, the transaction is handled in the financial system core 514 that, for example, breaks down the transaction in several sub-transactions - one for each account holder - and performs required lookups, such as verifying the account holder and account status. As a part of this flow, account information is read up - such as the current balance, account related configuration (e.g. if the account is interest bearing), and so on.

[0055] The process described above with respect to the system 500 is further explained in an example with an interest bearing account with a monthly interest payout period and a daily granularity in the context of other figures.

[0056] FIG. 6 illustrates accumulated balance calculations according to an embodiment. The figure shows examples of records, where both accumulated balance, period details (e.g., start of period), and last updated timestamp are recorded. The figure illustrates certain account changes for one account id (id 1, account id 6e50abc... in the figure), with other accounts also being recorded in the table.

[0057] FIG. 7 illustrates a flowchart according to an embodiment. As shown, in process 700, a system (such as system 500) may be handling a financial system transaction at 702. At 704, the system may fetch the account holder and perform some basic checks (e.g., existing, valid account). At 706, the account balance and details are read. At 708, it is checked whether itis an interest bearing account. If not, the process continues to 710, doing rating and calculating account changes and 712, writing account changes. If so, the process continues to 714, find current period for account, and 716, accumulate balance. The steps at 708, 714, and 716 may be grouped together as accumulated (or average) balance calculation logic. Certain embodiments of the accumulate balance performed at 716 are also described in greater detail in the context of FIG. 8.

[0058] Before the final financial operations (such as transfer money) are performed, the interest-bearing logic and accumulated (or average) balance calculation are done. If this is the first transaction in a new slice, the balance for the previous slice may be accumulated in one row for each account and period. If this is not the first transaction in a new slice, as already noted, the accumulated balance for the previous slice will have already been completed.

[0059] Keeping track of the accumulated balance “per period” is needed in case the balances are supposed to be used as part of interest calculations for a certain interest period (e.g., monthly, quarterly, yearly, etc.).

[0060] If the balance remains unchanged for several slices, there will be a catch-up calculation mechanism the next time the balance is changed, to cover for the missing slices in the balance accumulated for the period. If there would be no balance update for the whole period, there would be a catch-up calculation mechanism as part of the final period interest calculation and payout.

[0061] FIG. 8 illustrates a flowchart according to an embodiment. In particular, the figure shows an accumulated balance flow as an example of the accumulate balance calculation performed at 716 in the context of FIG. 7. The flow for calculating and updating the balance entry for the period is now described.

[0062] Finding current interest period

[0063] Given that the account is eligible for an accumulated balance calculation (e.g., it is interest-bearing), the first step of the flow determines which period is the current period. This was illustrated at 716. Knowing which period is the current period is needed in order to perform the correct catch-up calculation described later in the flow. After this, either of the flows A (802), B (806) or C (810) will be performed.

[0064] A. Is there any recorded balance entry (in the accumulated / average balance table) for this account yet?

[0065] At 802, there is a check of whether the account has had any accumulated / average balance entry recorded before, or if this is the first occurrence. If it is the first occurrence, then the calculation at 804 is performed. That calculation involves creating a balance entry (BE) with Balance = BBC*SGAP, Period = Current Period (CP), and LastUpdated = End of last slice (EOL). In this formula, BBC represents the balance before change (that is, the account balance before the balance change transaction); and SGAP represents the number of slices between last update and end of last slice or start of period.

[0066] The following is an example. Given that the account is not earlier covered with balance entries, the period is February, the granularity is hours, the previous balance was 100, the new balance is 90, and the current time is 2024-02-03 01:00, the following balance entry is created:Balance = 100 * 48 = 4800Period = FebruaryLast Updated= 2024.02.03 00:00

[0067] If the check concludes that there has been an accumulated / average balance entry recorded before, then the process continues to the next check.

[0068] B . Is the last balance entry in the current period?

[0069] At 806, there is a check of whether the last accumulated / average balance entry recorded for the account occurred in the current period, or if it was from a prior period. If the last balance entry recorded is not for the current period, then the calculation at 808 is performed. That calculation involves updating the latest balance entry (LBE) (i.e., the balance entry for the prior period), with Balance += BBC*PGAP, LastUpdated = LBE.periodEnd. Here, “+=” indicates that the value of BBC*PGAP is added to the prior accumulated balance recorded in the LBE. Additionally, the calculation at 808 involves creating a new balance entry for the current period, with Balance = BBC*SGAP, Period = CP, and LastUpdated = EOL.

[0070] The following is an example. Given that the current period is April, the granularity is daily, the current date is April 4, the new balance is 90, the latest balance update was March 29, the LBE.balance (the accumulated balance) is 2700, and the account balance before change was 110, the LBE is updated as follows, and the new BE is created as follows:(March) LBE.Balance = 2700 + 110 * 2(March) LBE. Last Updated = 2024-03-31(April) BE.Balance= 110 * 3(April) BE.Last Update = 2024-04-03

[0071] If the check concludes that there has been an accumulated / average balance entry recorded before, and it is for the current period, then the process continues to the next check.

[0072] C. Is balance entry up to date until yesterday?

[0073] At 810, there is a check of whether the last accumulated / average balance entry recorded for the account occurred, which is for the current period, is up to date until the end of the last slice. If the last balance entry recorded is not up to date until the end of the last slice, then the calculation at 812 is performed. That calculation involves updating the balance entry with Balance += BBC*SGAP, and LastUpdated = EOL.

[0074] The following is an example. Given that the period is April, the granularity is seconds, the time is 2024-04-0202:00:01, and the balance entry was last updated is 2024-04-02 01:00:00, the balance (the accumulated balance so far) was 9504000, and the account balance before change was 110, and the new balance is 90, the BE is updated as follows:Balance = 9504000 + 110 * 3600Last Updated = 2024-04-02 02:00:00

[0075] Possible extensions

[0076] The accumulated (or average) balance calculation described herein may have a number of different use cases, over and above what has so far been described. Some of these are described below.

[0077] Real-time interest on overdraft loans

[0078] Overdraft is a type of credit functionality that allows an account holder to go negative on their balance. These types of loans may also be called micro-loans / advance / credit depending on the country / region.

[0079] An account holder must apply for the possibility of having this type of credit and whenever they utilize this credit it would also imply that they will pay an “access fee” and additional interest for the money that they “borrow” from a “overdraft loan provider.”

[0080] Current interest calculations for small credit / overdraft / advance loans are typically calculated based on the remaining debt at the end of the day. Repayment of these credits are typically not based on dedicated loan repayment operations but is instead automatically made whenever money is put into the account again as part of any crediting transactions (access fees and interest are paid first).

[0081] There is then a nightly job that looks at the end of day balances and calculates how much interest that shall be added to the already existing debt. This process may need to process a lot of accounts and perform calculations and DB updates for each one of the accounts that are still in debt. This simply doesn’t scale very well, and it also has the drawback of having a rather large granularity where the loan provider will only be able to charge interest for “full days.”

[0082] One use case is therefore to start using the accumulated balances calculations as described above (e.g., triggering updates when a balance change is made and the granularity configuration), and to also introduce “real-time interest calculations.” Real-time interest calculations would be based on the average balance information and would calculate the actual interest down to the chosen granularity / “slice” whenever anyone is:• Looking at the debt (fetching the credit / overdraft / advance details).• When the debt is partially or fully repaid.• When / if an overdraft report is created.

[0083] By using real-time interest calculations, it would be possible to spread the processing load over the entire day, minimizing the number of database updates and making itpossible for the loan provider to earn extra interest as they can charge interest per hour / minute / half day / etc. (depending on the chosen granularity).

[0084] Interest prediction

[0085] As part of doing the stored accumulated balance and doing average calculations based on that, it would be possible to trigger other actions, such as showing an interest prediction (e.g., given that you keep having x amount of money on your account for the rest of the period, you would get y interest in the end of the period), or even doing interest payout for the slices that have passed in the period.

[0086] Bonus based

[0087] A bonus based on having an account balance above a certain amount during a full period may be provided. For example, the bonus may be triggered if the account holder has had over a certain amount, in average, on the account during the period, e.g., - “Get a bonus of 100 loyalty points if you have had more than 10 000 SEK in average on your account during January - March."

[0088] Flexible payouts

[0089] The interest payout may be triggered after a period ends and / or on account balance changes. A trigger for interest payout may occur for accounts where the balance is read or updated during a period before the scheduled payout job runs. In that way, the accounts that need to be updated by the scheduled job are reduced. For example, this may occur just after a period is over, and the balance change (triggered by the interest payout which changes the balance) may trigger that a new balance entry for the new period is created.

[0090] Short span loans

[0091] Today's loans tend to have a high granularity, but the technique provided herein could be used for loans as well to apply the loan interest only for exactly the time you had the loan. This might open up a possibility for new types of loans, e.g., for day trading or similar short span loans.

[0092] FIG. 9 is a flowchart illustrating a process 900 performed by a financial system of calculating interest during a financial transaction. Process 900 may begin in step s902.

[0093] Step s902 comprises, during a financial transaction for an account involving a balance change, (i) reading account information for the account, (ii) tracking an interest amount associated with the account based on the balance change, and (iii) writing updated account information for the account.

[0094] Step s902 comprises, at the end of a current interest period, calculating an interest for the account using the tracked interest amount.

[0095] In some embodiments, writing updated account information for the account comprises using a single database transaction to write results of the balance change and the tracked interest amount. In some embodiments, tracking an interest amount associated with the account comprises recording an average balance associated with the account. In some embodiments, tracking an interest amount associated with the account comprises recording an accumulated balance associated with the account and wherein calculating an interest for the account using the tracked interest comprises computing an average balance associated with the account based on the accumulated balance.

[0096] In some embodiments, tracking an interest amount associated with the account comprises determining that no tracking balance entry exists for the account and, as a result of determining that no tracking balance entry exists for the account, creating a tracking balance entry with a tracking balance amount equal to BBC*SGAP, where BBC represents a balance associated with the account prior to the balance change, and SGAP represents a number of slices between a start of a current interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period. In some embodiments, tracking an interest amount associated with the account comprises determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a prior interest period, wherein the prior tracking balance entry has a prior tracking balance amount, and, as a result of determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a prior interest period, creating (i) a first tracking balance entry with a first tracking balance amount equal to Balance + BBC*PGAP and (2) a second tracking balance entry with a second tracking balance amount equal to BBC*SGAP, wherein Balance represents the prior tracking balance amount, BBC represents a balance associated with the account prior to the balance change, PGAP represents a number of slicesbetween a slice when the prior tracking balance entry was updated and the end of the prior interest period, and SGAP represents a number of slices between a start of a current interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

[0097] In some embodiments, tracking an interest amount associated with the account comprises determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a current interest period, wherein the prior tracking balance entry has a prior tracking balance amount, and, as a result of determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a current interest period, creating a tracking balance entry with a tracking balance amount equal to Balance + BBC*SGAP, where Balance represents the prior tracking balance amount, BBC represents a balance associated with the account prior to the balance change, and SGAP represents a number of slices between a start of the interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

[0098] In some embodiments, the fixed granularity is at least an order of magnitude smaller than the interest period. In some embodiments, the interest period is one or more months and the fixed granularity is one day or less. In some embodiments, the method further includes performing an interest payout to the account based on the calculated interest. In some embodiments, the method further includes, prior to the end of the current interest period, estimating and providing a predicted interest amount for the current interest period based on the tracked interest amount. In some embodiments, calculating an interest for the account using the tracking balance entry comprises updating the tracking balance entry associated with the account and computing a final average balance over the current interest period. In some embodiments, the method further includes, prior to the end of the current interest period, estimating and providing a predicted interest amount for the current interest period based on the tracking balance entry.

[0099] FIG. 10 is a block diagram of apparatus 1000 (e.g., financial system 506, or part of financial system 506 such as financial system core 514 and average balance calculator 518), according to some embodiments, for performing the methods disclosed herein. As shown in FIG. 10, apparatus 1000 may comprise: processing circuitry (PC) 1002, which may include one ormore processors (P) 1055 (e.g., a general purpose microprocessor and / or one or more other processors, such as an application specific integrated circuit (ASIC), field-programmable gate arrays (FPGAs), and the like), which processors may be co-located in a single housing or in a single data center or may be geographically distributed (i.e., apparatus 1000 may be a distributed computing apparatus); at least one network interface 1048 comprising a transmitter (Tx) 1045 and a receiver (Rx) 1047 for enabling apparatus 1000 to transmit data to and receive data from other nodes connected to a network 1010 (e.g., an Internet Protocol (IP) network) to which network interface 1748 is connected (directly or indirectly) (e.g., network interface 1048 may be wirelessly connected to the network 1010, in which case network interface 1048 is connected to an antenna arrangement); and a storage unit (a.k.a., “data storage system”) 1008, which may include one or more non-volatile storage devices and / or one or more volatile storage devices. Interface 1060 may connect PC 1002 and storage unit 1008, interface 1062 may connect PC 1002 and network interface 1048, and interface 1064 may connect network interface 1048 and network 1010. In embodiments where PC 1002 includes a programmable processor, a computer program product (CPP) 1041 may be provided. CPP 1041 includes a computer readable medium (CRM) 1042 storing a computer program (CP) 1043 comprising computer readable instructions (CRI) 1044. CRM 1042 may be a non-transitory computer readable medium, such as, magnetic media (e.g., a hard disk), optical media, memory devices (e.g., random access memory, flash memory), and the like. In some embodiments, the CRI 1044 of computer program 1043 is configured such that when executed by PC 1002, the CRI causes apparatus 1000 to perform steps described herein (e.g., steps described herein with reference to the flow charts). In other embodiments, apparatus 1000 may be configured to perform steps described herein without the need for code. That is, for example, PC 1002 may consist merely of one or more ASICs. Hence, the features of the embodiments described herein may be implemented in hardware and / or software.

[0100] While various embodiments are described herein, it should be understood that they have been presented by way of example only, and not limitation. Thus, the breadth and scope of this disclosure should not be limited by any of the above described exemplary embodiments. Moreover, any combination of the above-described embodiments in all possiblevariations thereof is encompassed by the disclosure unless otherwise indicated herein or otherwise clearly contradicted by context.

[0101] Additionally, while the processes described above and illustrated in the drawings are shown as a sequence of steps, this was done solely for the sake of illustration. Accordingly, it is contemplated that some steps may be added, some steps may be omitted, the order of the steps may be re-arranged, and some steps may be performed in parallel.

Claims

CLAIMS1. A method performed by a financial system (506) of calculating interest during a financial transaction, the method comprising: during (s902) a financial transaction for an account involving a balance change, (i) reading (706) account information for the account, (ii) tracking (716) an interest amount associated with the account based on the balance change, and (iii) writing (712) updated account information for the account; and at the end of a current interest period, calculating (s904) an interest for the account using the tracked interest amount.

2. The method of claim 1, wherein writing (712) updated account information for the account comprises using a single database transaction on a database (516) to write results of the balance change and the tracked interest amount.

3. The method of any one of claims 1-2, wherein tracking (716) an interest amount associated with the account comprises recording an average balance associated with the account.

4. The method of any one of claims 1-2, wherein tracking an interest amount associated with the account comprises recording an accumulated balance associated with the account and wherein calculating (s904) an interest for the account using the tracked interest comprises computing an average balance associated with the account based on the accumulated balance.

5. The method of any one of claims 1-4, wherein tracking (716) an interest amount associated with the account comprises determining (802) that no tracking balance entry exists for the account and, as a result of determining that no tracking balance entry exists for the account, creating (804) a tracking balance entry with a tracking balance amount equal to BBC*SGAP, where BBC represents a balance associated with the account prior to the balance change, and SGAP represents a number of slices between a start of a current interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

6. The method of any one of claims 1-4, wherein tracking (716) an interest amount associated with the account comprises determining (806) that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a prior interest period, wherein the prior tracking balance entry has a prior tracking balance amount, and, as a result of determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a prior interest period, creating (808) (i) a first tracking balance entry with a first tracking balance amount equal to Balance + BBC*PGAP and (2) a second tracking balance entry with a second tracking balance amount equal to BBC*SGAP, wherein Balance represents the prior tracking balance amount, BBC represents a balance associated with the account prior to the balance change, PGAP represents a number of slices between a slice when the prior tracking balance entry was updated and the end of the prior interest period, and SGAP represents a number of slices between a start of a current interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

7. The method of any one of claims 1-4, wherein tracking (716) an interest amount associated with the account comprises determining (810) that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a current interest period, wherein the prior tracking balance entry has a prior tracking balance amount, and, as a result of determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a current interest period, creating (812) a tracking balance entry with a tracking balance amount equal to Balance + BBC*SGAP, where Balance represents the prior tracking balance amount, BBC represents a balance associated with the account prior to the balance change, and SGAP represents a number of slices between a start of the interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

8. The method of any one of claims 5-7, wherein the fixed granularity is at least an order of magnitude smaller than the interest period.

9. The method of any one of claims 5-7, wherein the interest period is one or more months and the fixed granularity is one day or less.

10. The method of any one of claims 1-9, further comprising performing an interest payout to the account based on the calculated interest.

11. The method of any one of claims 1-10, further comprising, prior to the end of the current interest period, estimating and providing a predicted interest amount for the current interest period based on the tracked interest amount.

12. The method of any one of claims 1-11, wherein calculating (s904) an interest for the account using the tracking balance entry comprises updating the tracking balance entry associated with the account and computing a final average balance over the current interest period.

13. The method of any one of claims 1-12, further comprising, prior to the end of the current interest period, estimating and providing a predicted interest amount for the current interest period based on the tracking balance entry.

14. A financial system (506) comprising: processing circuitry (1002); and a memory, the memory containing instructions (1044) executable by the processing circuitry (1002), whereby when executed the processing circuitry (1002) is configured to: during a financial transaction for an account involving a balance change, (i) read (706) account information for the account, (ii) track (716) an interest amount associated with the account based on the balance change, and (iii) write (712) updated account information for the account; and at the end of a current interest period, calculate an interest for the account using the tracked interest amount.

15. The financial system of claim 14, wherein writing (712) updated account information for the account comprises using a single database transaction on a database (516) to write results of the balance change and the tracked interest amount.

16. The financial system of any one of claims 14-15, wherein tracking (716) an interest amount associated with the account comprises recording an average balance associated with the account.

17. The financial system of any one of claims 14-15, wherein tracking an interest amount associated with the account comprises recording an accumulated balance associated with the account and wherein calculating an interest for the account using the tracked interest comprises computing an average balance associated with the account based on the accumulated balance.

18. The financial system of any one of claims 14-17, wherein tracking (716) an interest amount associated with the account comprises determining that no tracking balance entry exists for the account and, as a result of determining that no tracking balance entry exists for the account, creating a tracking balance entry with a tracking balance amount equal to BBC*SGAP, where BBC represents a balance associated with the account prior to the balance change, and SGAP represents a number of slices between a start of a current interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

19. The financial system of any one of claims 14-17, wherein tracking (716) an interest amount associated with the account comprises determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a prior interest period, wherein the prior tracking balance entry has a prior tracking balance amount, and, as a result of determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a prior interest period, creating (i) a first tracking balance entry with a first tracking balance amount equal to Balance + BBC*PGAP and (2) a second tracking balance entry with a second tracking balance amount equal to BBC*SGAP, wherein Balance represents theprior tracking balance amount, BBC represents a balance associated with the account prior to the balance change, PGAP represents a number of slices between a slice when the prior tracking balance entry was updated and the end of the prior interest period, and SGAP represents a number of slices between a start of a current interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

20. The financial system of any one of claims 14-17, wherein tracking (716) an interest amount associated with the account comprises determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a current interest period, wherein the prior tracking balance entry has a prior tracking balance amount, and, as a result of determining that a prior tracking balance entry exists for the account and the prior tracking balance entry is for a current interest period, creating a tracking balance entry with a tracking balance amount equal to Balance + BBC*SGAP, where Balance represents the prior tracking balance amount, BBC represents a balance associated with the account prior to the balance change, and SGAP represents a number of slices between a start of the interest period and an end of a last slice, wherein a slice is a time period of a fixed granularity smaller than a duration of the current interest period.

21. The financial system of any one of claims 18-20, wherein the fixed granularity is at least an order of magnitude smaller than the interest period.

22. The financial system of any one of claims 18-20, wherein the interest period is one or more months and the fixed granularity is one day or less.

23. The financial system of any one of claims 14-22, further comprising performing an interest payout to the account based on the calculated interest.

24. The financial system of any one of claims 14-23, further comprising, prior to the end of the current interest period, estimating and providing a predicted interest amount for the current interest period based on the tracked interest amount.

25. The financial system of any one of claims 14-24, wherein calculating (s904) an interest for the account using the tracking balance entry comprises updating the tracking balance entry associated with the account and computing a final average balance over the current interest period.

26. The financial system of any one of claims 14-25, further comprising, prior to the end of the current interest period, estimating and providing a predicted interest amount for the current interest period based on the tracking balance entry.

27. A computer program (1043) comprising instructions which when executed by processing circuitry (1002) of a node (1000), causes the node (1000) to perform the method of any one of claims 1-13.

28. A carrier containing the computer program (1043) of claim 27, wherein the carrier is one of an electronic signal, an optical signal, a radio signal, and a computer readable storage medium (1042).

Images