Patent Application
20240386491
Conventional employment relationships operate on an accrued wages model in which workers perform their jobs, record their time and/or attendance (in some instances), and after some period of time are paid wages for a preceding pay period. Although many workers have adequate funds to pay their monthly expenses, due to infrequent expenses such as a vacation, unexpected medical expenses or even unexpected outlays such as car repairs, many workers either live paycheck to paycheck, or simply need additional funds temporarily to cover unanticipated costs. In most cases, consumers may resort to credit cards, which have high fees and interest rates, friends and family (which may or may not be available or practical), bank overdraft, pawn shops or even short-term loans such as payday loans or the like, which have high fees and interest rates. All the while, the employer essentially “owes” the employee a certain portion of their wages for work performed, but because the end of the pay period has not yet arrived, the employee cannot access or use these owed monies. What is needed, therefore, are techniques and supporting systems that facilitate early access to earned and accrued wages in an efficient and cost-effective manner while mitigating a risk of mismanaging accounting ledgers between various sources of funds.
Disclosed herein, in some aspects, is a system for disbursing advanced wages to an employee prior to a payment date of scheduled wages for a pay period, the system comprising one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, cause the system to perform operations including: identifying a predictable pattern for i) the amount of scheduled wages received by the employee, ii) the frequency of the scheduled wages received, iii) a rate at which the scheduled wages are accrued during the pay period (“pay rate”), or iv) a combination thereof; calculating an amount of advanced wages available (“max advanced wages”) for disbursement to the employee, the max advanced wages based on i) the cumulative time worked by the employee during the pay period, ii) the predictable pattern, iii) expenditures by the employee, iv) a threshold percentage of the predicted pattern amount of the scheduled wages, v) a threshold amount, or vi) a combination thereof; and automatically directing a flow of funds between two or more financial accounts associated with the system (“system accounts”), so as to provide a safeguard for a disbursement account used to disburse advanced wages to the employee, wherein the system is configured to set a limit of an amount available to be disbursed by the disbursement account (“disbursement limit”) based at least partially on the max advanced wages; wherein any one of the one or more processors is configured to be in communication with one or more financial accounts associated with the employee (“employee account”), the two or more system accounts, the disbursement account, or any combination thereof, so as to perform operations from one or more of (a)-(c).
Disclosed herein, in other aspects, is a non-transitory computer readable medium for disbursing advanced wages to an employee prior to a payment date of scheduled wages for a pay period, the non-transitory computer readable medium comprising instructions that, when executed by a processor, cause the processor to perform operations including: identifying a predictable pattern for i) the amount of scheduled wages received by the employee, ii) the frequency of the scheduled wages received, iii) a rate at which the scheduled wages are accrued during the pay period (“pay rate”), or iv) a combination thereof; calculating an amount of advanced wages available (“max advanced wages”) for disbursement to the employee, the max advanced wages based on i) the cumulative time worked by the employee during the pay period, ii) the predictable pattern, iii) expenditures by the employee, iv) a threshold percentage of the predicted pattern amount of the scheduled wages, v) a threshold amount, or vi) a combination thereof; and automatically directing a flow of funds between two or more financial accounts associated with a system (“system accounts”), so as to provide a safeguard for a disbursement account used to disburse advanced wages to the employee, wherein the processor is configured to set a limit of an amount available to be disbursed by the disbursement account (“disbursement limit”) based at least partially on the max advanced wages; wherein the processor is configured to be in communication with one or more financial accounts associated with the employee (“employee account”), the two or more system accounts, the disbursement account, or any combination thereof, so as to perform operations from one or more of (a)-(c).
Disclosed herein, in other aspects, is a method for disbursing advanced wages to an employee prior to a payment date of scheduled wages for a pay period, the method comprising: identifying a predictable pattern for i) the amount of scheduled wages received by the employee, ii) the frequency of the scheduled wages received, iii) a rate at which the scheduled wages are accrued during the pay period (“pay rate”), or iv) a combination thereof; calculating an amount of advanced wages available (“max advanced wages”) for disbursement to the employee, the max advanced wages based on i) the cumulative time worked by the employee during the pay period, ii) the predictable pattern, iii) expenditures by the employee, iv) a threshold percentage of the predicted pattern amount of the scheduled wages, v) a threshold amount, or vi) a combination thereof; and automatically directing a flow of funds between two or more financial accounts associated with a system (“system accounts”), so as to provide a safeguard for a disbursement account used to disburse advanced wages to the employee, wherein the a limit of an amount available to be disbursed by the disbursement account (“disbursement limit”) is based at least partially on the max advanced wages.
These and other features, aspects, and advantages of some embodiments will become better understood with regard to the following description and accompanying drawings.
Terms used in the claims and specification are defined as set forth below unless otherwise specified.
The term “employee”, as used herein, refers to a person that is employed and receives wages from an employer. The term “employee” and “worker” may be used interchangeably herein.
The term “earnings” refers to unpaid wages for time worked by the employee.
The term “funds”, as used herein refers to a monetary value, corresponding to any currency, such as U.S. Dollars, Canadian Dollar, Euro, and any Cryptocurrency.
The term “wages”, as used herein, refers to payment received for time worked by the employee.
The phrase “and/or,” as used in the specification and in the claims, should be understood to mean “either or both” of the elements so conjoined, i.e., elements that are conjunctively present in some cases and disjunctively present in other cases. Multiple elements listed with “and/or” should be construed in the same fashion, i.e., “one or more” of the elements so conjoined. Other elements may optionally be present other than the elements specifically identified by the “and/or” clause, whether related or unrelated to those elements specifically identified. Thus, as a non-limiting example, a reference to “A and/or B”, when used in conjunction with open-ended language such as “comprising” can refer, in one embodiment, to A only (optionally including elements other than B); in another embodiment, to B only (optionally including elements other than A); in yet another embodiment, to both A and B (optionally including other elements).
As used in the specification and in the claims, “or” should be understood to have the same meaning as “and/or” as defined above. For example, when separating items in a list, “or” or “and/or” shall be interpreted as being inclusive, i.e., the inclusion of at least one, but also including more than one, of a number or list of elements, and, optionally, additional unlisted items. Only terms clearly indicated to the contrary, such as “only one of” or “exactly one of,” or, when used in the claims, “consisting of,” will refer to the inclusion of exactly one element of a number or list of elements. In general, the term “or” as used shall only be interpreted as indicating exclusive alternatives (i.e., “one or the other but not both”) when preceded by terms of exclusivity, such as “either,” “one of,” “only one of,” or “exactly one of.”
Described herein, in some embodiments, are systems and methods for automating funds movement to pay back credit expenditures. In some embodiments, systems and methods herein include a credit card that is partially-secured, such that at least a portion of a user's paycheck is used as collateral for expenditures incurred by the credit card. Accordingly, in some embodiments, such automated funds (e.g., money) movement enables the user to potentially improve their credit score with on-time payments to credit card balances, and/or for the user to improve financial habits due to restrictions on unsecured credit being used.
In some embodiments, the partially-secured credit card (“Earnings Card” as described herein) is configured to allow an employee to access wages earned through employment but not yet paid or received. As used herein, the term “earnings” refers to said unpaid wages. In some embodiments, said earnings correlate with employment during a given pay period, wherein said earnings for the given pay period correspond to the wages for the given pay period. In some embodiments, the said earnings are accumulated throughout the pay period, for example hourly, daily, every other day, weekly, etc. As a result, systems and methods described herein allow employees (e.g., workers) to access and use money earned but not yet paid (i.e., earnings) by the employee's employer. Such earnings may be used to pay bills, purchase goods and services, and otherwise enjoy their unpaid wages prior to the end of a pay period and before their employer has released the funds (e.g., for the wages). Additional intended uses of the invention can include avoiding overdraft fees and avoiding carrying a balance on a credit card. These earnings may be transferred to the employee, who may withdraw it as cash or use it as digital currency or virtual goods within an electronic marketplace.
Accordingly, in some embodiments, for any system described herein, the Earnings Card is configured to operate with a dynamic credit balance, wherein the credit is based on available earnings accrued. For example, in some embodiments, the employee is able to access cash and/or make expenditures using the Earnings Card up to the amount of available earnings As described herein, in some cases, the employee is able to make additional expenditures using the Earnings Card via funds available in other accounts (as described herein).
In some embodiments, as described herein, the system is configured to predict the amount of wages received by the employee for a given pay cycle and/or the frequency of receiving said wages, wherein said wages paid by an employer for a given pay cycle (or pay period) may be referred to herein as scheduled wages. In some embodiments, as described herein, the scheduled wages are paid on a payment date of a pay cycle. In some embodiments, as described herein, the system is configured to verify the employment status of the employee during the pay period, thereby allowing the earnings corresponding to the unpaid wages for the time worked (during the given pay period) to be accessible to the employee. In some embodiments, the employment status is automatically verified. In some embodiments, an employment status correlates to continued employment by the employee and/or changes that may impact employment stability. In some embodiments, the employment status is verified through one or more employment verifiers, which may comprise work email status, global positioning system (“GPS”) location identifiers, payroll active status, an employee risk score, previous restore and/or restore failure records (as described herein), timesheet, user income stability type, employment status prediction using a machine learning model, or any combination thereof.
In some embodiments, the system comprises one or more computing devices, and one or more components of a network and/or server, for example as described herein in
In some embodiments, the system is configured to function similar to that of a financial institution (e.g., a bank). For example, in some embodiments, the system functions, at least in part, similar to that of a checking account at a bank. In some cases, the system however updates an earnings balance in said similar “checking account”, so as to provide an employee with access to said earnings in advance of a pay date (or pay cycle). In some cases, such earnings balance is updated frequently (e.g., hourly, daily, in real-time) as time is worked and in advance of a pay date for the wages.
Accordingly, in some cases, the system is configured to assign a profile for the employee that is specific to the employee's information, such as earnings available, employment status, etc. In some embodiments, a system described herein is configured to receive and/or disburse funds (e.g., any type of currency, such as U.S. Dollar, Euro, Canadian Dollar, Cryptocurrency, etc.). In some embodiments, the system is configured to function similar to that of the remote processing device and/or remote server described in U.S. Pat. No. 9,202,250, the entirety of which is incorporated herein by reference. In some embodiments, funds are configured to be transferred to the system, for example, to the profile associated with the employee (e.g., funds may be transferred by another financial institution, the employee, or other third party). In some embodiments, funds are configured to be direct deposited to the system from, for example, an employer wage disbursement system. In some embodiments, funds are configured to be transferred out by the employee, to, for example, a financial institution, a merchant, another individual, etc. In some embodiments, the employee is able to access funds from the system using a monetary dispensing apparatus (e.g., ATM machine). In some embodiments, the employee is able to access funds using a payment card, which may act similar to that of a debit card.
In some embodiments,
As described herein, in some embodiments, the Earnings tool 100 is configured to determine an amount of earnings accessible to the employee. In some cases, the Earnings tool accesses third party information to verify the employee has indeed worked, and thereby earned such earnings. In some cases, the Earnings tool is configured to determine the amount of earnings available, based on expenditures by the employee.
In some embodiments, the PD module 102 is configured to determine the parameters that define the amount of earnings earned by the employee during a given pay period. In some embodiments, the PD module is configured to determine the eligibility of the employee to use the system, and/or to on-board an employee with the required information.
In some embodiments, the PD module is configured to determine said eligibility of the employee based on one or more employment characteristics, such as type and/or name of employer, length of employment by the employee, frequency of wages received (e.g., pay cycle), amount of wages received, expenditures by the employee, validation of a paycheck, or any combination thereof. In some embodiments, the PD module 102 is configured to determine whether the employee receives a paycheck (e.g., regular wages) from the employer in a predictable manner. For example, in some cases the PD module is provided access to the employee's account at a financial institution (e.g., a bank, such as Bank of America, Chase, etc.), so as to review the account history to determine the amount and frequency of any direct deposits or other deposits (e.g., checks, cash) that correlate with wages from an employment. In some embodiments, the PD module determines a predictability of the wages based on a frequency of direct deposits detected in the account and an amount. In some embodiments, the PD module is configured to group transactions, so as to identify transactions that correlate with direct deposits or cash/check deposits associated with wages. In some embodiments, the PD module is configured to group multiple sets of wages if the employee has multiple employers.
For example, in some embodiments, the PD module identifies wages as being predictable from an employer if there are at least 2, 3, 5, 10, or more direct deposits detected in the account. In some cases, the PD module further determines a frequency of the direct deposits, for example weekly, bi-weekly, monthly, number of days, etc. In some cases, the PD module determines whether the amount of the direct deposits is consistent, or within a certain tolerance, such as within at most 1%, 2%, 5%, 10%, or 20% of each other. In some embodiments, the PD module correlates with a frequency of wages based on employment type. For example, in some embodiments, where the employer is the military, only one direct deposit is needed as the PD module includes stored information relating to military wage disbursements. In some cases, if the employer is listed as a preferred employer, the PD module requires only two direct deposits to confirm the wages as being predictable. In such cases, an employer may be a preferred employer based on a predetermined list of employers and/or characteristics provided by the employee.
In some embodiments, where one or more direct deposits are missing such that a pattern of wages received cannot be determined, the PD module is configured to automatically alert an agent (associated with the system), and/or request the employee upload a paystub for verification.
In some embodiments, where wages are deposited into the employee's account via cash and/or check deposits, the PD module is configured to automatically alert an agent (associated with the system), and/or request the employee to upload a plurality of paystubs, so as to determine a frequency of the wages received, and amount (as described herein).
In some embodiments, the PD module determines an hourly rate of the employee. In some embodiments, the hourly rate is based on an amount of deposits made to an account (e.g., in a financial institution) divided by the number of hours worked by the employee in the given pay period. In some embodiments, the hours worked is determined based on the length of the pay period. For example, in some cases, a weekly deposit correlates to 40 hours of time worked by the employee, whereas a bi-weekly deposit correlates to 80 hours. In some cases, the PD module correlates against a paystub to verify the hours worked. In some cases, the hourly rate correlates to the net pay in the wages received by the employee (instead of gross pay). Accordingly, in some cases, the net pay correlates to wages received after taxes and other deductions have been removed. In some embodiments, said hourly rate is used by the Available Earnings tool to determine earnings by the employee.
In some cases, the employee requires a minimum hourly rate in order to be eligible by the system for accessing earnings. In some embodiments, the minimum hourly rate is at least from about $0.1 to about $100 per hour, such as for example, from about $1 to about $50 per hour, from about $2 to about $25 per hour, from about $3 to about $15 per hour, for example at least about $3 to about $10 per hour, or about $4 per hour.
In some embodiments, the PD module determines a payment schedule for when the employee is expected to receive wages. In some embodiments, the PD module determines a correlating work schedule for a given pay period that aligns with the payment schedule. In some embodiments, the PD module is configured to receive input and/or automatically adjust for holidays, weekends, vacations, sick days, etc.
In some embodiments, the AE module 104 is configured to determine the amount of earnings available to the employee. As described herein, in some embodiments the available earnings correspond to the time worked by the employee during a given pay period (e.g., in advance of receiving the wages according to the normal pay schedule). As described below (e.g.,
In some embodiments, the earnings available is determined based on actual earned income less any expenditures made by the employee during the pay period. In some embodiments, the actual earned income corresponds to the hours worked by the employee during a given pay period multiplied by the employee's hourly rate (as determined by the PD module for example).
In some embodiments, the earnings are accumulated according to a predetermined frequency. For example, in some embodiments, the earnings are accumulated hourly (for each hour worked), every four hours (e.g., each half day worked), daily, every other day, weekly, every ten days, bi-weekly, monthly, etc. As described herein, the earnings are accumulated subject to clearance or “active status” per the Earnings Gatekeeper module.
In some embodiments, the expenditures correspond to funds and/or earnings withdrawn by the employee. In some embodiments, the expenditures correspond to payments made, and/or transfer of earnings to another account or individual. Accordingly, the expenditures may refer to the earnings accessed by the employee ahead of receiving the wages during the pay period. In some embodiments, the earnings are disbursed to the employee via a financial account associated with the system (e.g., “system account”, as described herein). In some embodiments, the system account essentially provides the funds associated with the system as the earnings, which may be withdrawn by the employee, transferred to another financial account associated with the employee, etc. In some embodiments, the AE module restricts the amount of expenditures allowed by the employee with respect to the earnings (e.g., restricts the accessible earnings). For example, in some cases, the AE module restricts the allowable expenditure of the earnings to a percentage amount of the total wages predicted to be received. In some embodiments, the AE module restricts the expenditure of the earnings to at most about 5%, 10%, 25%, 50%, 75%, 80%, 90% or 100% of the wages expected to be received (as predicted using the PD module for example). In some embodiments, the AE module restricts the expenditure of the earnings to a particular currency amount. For example, in some embodiments the AE module restricts the expenditure of the earnings to at most about $100 (U.S. dollar), $250, $500, $1,000, $2,000, $5,000, or $10,000. In some embodiments, the AE module restricts the expenditure of the earnings using a combination of a percentage of the total wages predicted and a currency amount. For example, in some embodiments, the AE module restricts the expenditure of the earnings from about 50% to about 90% of the total wages predicted, up to a maximum of from about $500 to about $2,000.
In some embodiments, as described herein, the system may be interfaced with the employee using a computing device (e.g., the system may be provided as an “app” on a mobile device).
In some embodiments, as described herein, the system may also include other funds (e.g., any currency or monetary value, such as U.S. Dollar), which is separate from the earnings. In some cases, where the wages are directly deposited or otherwise transferred to the system (e.g., to a profile associated with the employee), after the wages have been received for a given pay period, the available earnings are converted to the funds amount (e.g., “cash” as depicted in
In some embodiments, where wages are deposited into an account for another financial institution, the AE module is configured to reconcile the expenditures of the earnings (during the pay period) by automatically withdrawing the expenditure amount from the financial institution account. In other cases, for example where wages are directly deposited into the system, the amount of the expenditures are automatically deducted from the wages, and the remaining is added to the funds available (e.g., “cash” in
As described herein, in some embodiments, the earnings available is based on unpaid wages for time worked by the employee. Accordingly, earnings available may be presented to the employee according to pay period, wherein in some cases, once wages for a given pay period is received, the earnings available will then reflect the next pay period (e.g., pay cycle). In some embodiments, depending on when the wages are actually received by the employee, there may be an overlap in the earnings available between one pay period and the next pay period. Accordingly, in some cases, there may be an offset of when a pay period ends, and when the wages are actually paid.
As described herein, in some embodiments the system functions similar, in some aspects, to a checking account, wherein instead of waiting every pay cycle to access funds, the earnings balance is updated in advance of the pay cycle. In some case, the earnings balance is updated in real-time, hourly, daily, every other day, weekly, etc. for time worked, wherein these earnings may accessed and used for expenditures (as described herein, including for example cash withdrawal, purchasing items digitally, purchasing items at a store, making payments, transferring to another person or account, etc.). As described herein, a card may be used for such expenditures.
In some embodiments, the EG module 106 is configured to determine whether the employee is allowed to access the accumulated earnings during a given pay period. In some embodiments, the EG module must first determine whether the employee has an active employment before such accumulated earnings are determined. Accordingly, the earnings reported in
In some embodiments, the EG module is configured to verify an employment status during a pay period, so as to determine whether the employee has an active status (corresponding with an employment being verified) and is thereby allowed to access earnings (either currently available earnings, or future earnings). In some embodiments, the EG module is configured to verify an employments status of a user based on a work email status (e.g. work email verification, “WEV”), a location of the employee (e.g., via global positioning system (GPS) location identifiers), payroll active status, an employee risk score, previous restore and/or restore failure records (as described herein), timesheet, user income stability type, employment status prediction using a machine learning algorithm, or any combination thereof.
In some embodiments, the PD module is configured to determine whether the employee has an “active status” (and/or an “inactive status”) based on a location of the employee, and whether it correlates with a location for the employment (e.g., using GPS coordinates of the employee, employment location, predetermined geofence, etc.). In some embodiments, the location of the employee is determined via a location monitoring software. In some embodiments, the location is obtained using a computing device of the employee, such as a mobile device (e.g., smart device, smart phone, smart watch, etc.). In some cases, an employment key card is used to track when the employee enters and/or exits an employment facility. As described herein, in some cases, the EG module is configured to determine how long the employee was located at the location associated with the employment. For example, in some cases, the location of the employee may use a geofence to indicate an area of employment, and where the time and duration the employee entered an employment location and stayed there is accessible. Accordingly, as described herein, in some cases, the EG module is configured to restrict the amount of available earnings based on the number of hours the employee was located at an employment location, and/or send an alert (e.g., to the employee and/or a personnel associated with the system) for verification of hours worked (e.g., for that day).
In some embodiments, such active status (and/or “inactive status”) is determined based on use of an employment email, as described herein. For example, in some cases, the ES module will send an email with a verification link for the employee to click so as to verify employment status. In some cases, the employee is required to send an email to a prescribed email address to verify employment status. In some cases, such verification via email is required by the EG module, and via the ES module to be made hourly, daily, every other day, etc. If the employee fails to verify employment status, the EG module may restrict the available earnings (e.g., for that day). The EG module may also send an alert to the employee and/or other personnel to confirm employment status.
In some embodiments, as described herein, the Earnings tool is provided by one or more computing devices, wherein the Earnings tool can be embodied as a computer system (e.g., see
In some embodiments, the one or more decision engines applies one or more algorithms (e.g., an ML algorithm) to predict an employment status, where applying such an algorithm may be based on training data from historical records of users and other individuals (e.g., a cohort of individuals). In some embodiments, such training data includes labels for each set of respective data that corresponds to a user i) receiving a next paycheck (e.g., a next scheduled wages), or ii) not receiving a next paycheck (e.g., not receiving a next scheduled wages). In some embodiments, the set of respective data (both the training data, and corresponding data for the employee (referred to herein as “employment status data”)) includes one or more input parameters such as for example: past paycheck histories (such as missing records, paycheck sizes, arrival times, etc.), past user activities, which includes on the system (such as cashout/restore, login, CX contacts, etc.), past employment signal and earnings data, past bank transactions (such as spending behavior, competitor transactions, certain categories of trans. (loan, U-Haul, restaurant, etc.), etc.), and others.
Accordingly, in some embodiments, the ML model, via the training model, includes one or more features associated with a given weight in an overall calculation for predicting whether a next paycheck will be received. In some embodiments, such weights are updated based on additional data being provided as part of the training model.
In some embodiments, using the ML model, the EG module, for each user, performs a periodic evaluation (or an evaluation for a new user), using the features corresponding to the user so as to predict a probability output on whether the user receives the next paycheck. In some embodiments, such periodic evaluation occurs daily, every 2, 3, 4, 5, or 6 days, weekly, bi-weekly, based on pay period, or any combination thereof.
In some embodiments, the system is configured to send an alert to the employee, a system administrator, or both, if it is predicted that the employee will not receive a next paycheck (e.g., next scheduled wages).
In some cases, the EG module confirms an active status (and/or “inactive status”) using one or more activity indicators, such as for example using a software application, for example Zoom or Microsoft Teams, determine whether the employee was listed as “available” during a given day. In some embodiments, the EG module is configured to determine how long such a signal was received from the employment computing device correlating to an active status (e.g., how long the employee had an “available” status, an “away” status, and/or an “offline” status). For example, in some cases, the EG module is configured to determine that a signal correlating to an active status was received for only 4 hours in a given day. Accordingly, in some cases, the EG module restricts the available earnings to 4 hours for that day. In some cases, the EG module sends an alert to the employee or other personnel to confirm whether the employee indeed only worked 4 hours.
In some embodiments, the EG module is configured to access the employee's account at a financial institution (as described herein), so as to determine whether a deposit related to the employee's wages (e.g., direct deposit, cash deposit, check deposit) was made according to the predictable pattern determined via the PD module. In some embodiments, where direct deposits and/or other deposits related to wages are configured to be deposited to the system, the EG module is configured to determine whether such deposit aligns with the predictable pattern determined via the PD module.
For example, in some embodiments, the EG module verifies whether the actual wages received for a given pay period (and after earnings was made available) was on time and/or within a tolerance of the predicted amount (e.g., wages received at an account in another financial institution). In some cases, if the wages were received within about 24 hours, 36 hours, 48 hours, or 72 hours of the predicted pay date (e.g., as determined by the PD module), the employee will remain in an active status (providing there are no other clearance issues). In some embodiments, if the amount of wages received was within 5%, 10%, or 25% of the predicted amount (e.g., as determined by the PD module), the employee will remain in an active status (providing no other clearance issues). In some embodiments, if the amount of wages received was within 5%, 10%, or 25% of the predicted amount (e.g., as determined by the PD module), the employee will remain in an active status (providing no other clearance issues). Accordingly, where wages are received and then used to pay back the advance wages (earnings) obtained by the employee, such earnings have been restored. For example, as described herein, a system account may be configured to disburse the earnings (e.g., advanced wages) to the employee. Upon receiving the scheduled wages (e.g., paycheck), which may be configured to be direct deposited into the same or a different system account or an employee account, the disbursed earnings may then be deposited into the system account (that disbursed the earnings) to restore the expenditures. In some embodiments, the system account may be specific to the employee. In some embodiments, the disbursed earnings may be funds that are already in the system account, or they may be funds located in another system account that provides disbursed earnings, and receives back the restored amount upon the employee receiving a pay check (e.g., scheduled wages).
In some cases, where the wages received is outside a tolerance for receipt date and/or amount, the EG module will restrict future earnings being made available, and/or provide an alert to the employee and/or other personnel to confirm the predicted pay amount and pay date. For example, in some cases, the employee may have switched employers, or took a leave of absence, or quit. In some embodiments, one or more occurrences of wages received being outside a tolerance in amount and/or date, and/or the employee not having an active status due to actual hours worked, may result in the employee being identified by the EG module with a risk for employment stability. In cases where insufficient wages are received (e.g., including no wages received) to pay back the advanced wages obtained by the employee, such earnings are associated with a restore failure designation (e.g., a restore fault). Accordingly, the EG module may restrict future earnings being available until the employee restores their stability, which may be for example, similar to the on-boarding process by the PD module, where multiple direct deposits (or other deposits relating to wages) may be required.
In some embodiments, the Risk module 107 is configured to determine whether the employee is allowed to access the accumulated earnings during a given pay period. In some embodiments, the Risk module operates separately from the EG module. In some embodiments, the Risk module operates together with EG module to determine whether an employee is allowed to access earnings. In some embodiments, the EG module permits an employee to access their earnings based at least in part on information obtained via the Risk module.
In some embodiments, the Risk module is configured to determine a risk (e.g., risk level, risk score, etc.) associated with the employee, wherein the risk correlates at least in part as to whether the employee has and/or will earn wages so as to reconcile any earnings that were used (e.g., expenditures as described herein). For example, an employee determined with a high risk level may be attributed with a low likelihood of receiving wages as predicted (e.g., a next paycheck, next scheduled wages), while an employee with a low risk level may be attributed with a high likelihood of receiving wages as predicted. A high risk level may correlate with an inactive employment status, while a low risk level may correlate with an active employments status. In some embodiments, the risk (e.g., risk level, risk score, etc.) is determined based on or more risk factors. In some embodiments, the one or more risk factors comprise, financial institution (e.g., bank) transactions by the employee, email verification data, activity indicators (as described herein), location indicators (as described herein, e.g., when tracking location of the employee), other external data, or any combination thereof. For example, in some cases, the bank transactions relate to amount of wages actually deposited, frequency of wages deposited, amount of withdrawals, or any combination thereof. In some cases, a reduction in wages and/or one or more missed wages, as determined via deposits (e.g., direct deposits, cash deposits, check deposits, etc.), will be attributed with an increased risk (e.g., risk level, risk score, etc.). In some embodiments, a more frequent “inactive status”, for example as determined via email verification (as described herein), activity indicators, and/or location of employee, may result in an increased risk score. For example, in some cases, where the employee fails to verify email, has a decreased “available” status using activity indicators, and is detected (e.g., via a mobile device, an employee key card, etc.) to be outside an employment location for longer periods of time (or completely) will suggest the employee is not working according to a predetermined schedule, and thus access to the earnings may need to be restricted to avoid a risk of the employee using said earnings without having wages to reconcile with. In some embodiments, as described herein, one or more decision engines utilizes such risk factors for the employee stored as data on the system (e.g., risk factors data).
In some embodiments, the Risk module determines the risk (e.g., risk level, risk score, etc.) using one or more decision engines (as described herein). In some embodiments, the one or more decision engines applies one or more algorithms. In some cases, the Risk module uses a machine learning algorithm to better predict if an employee will not earn the predicted wages based on any combination of risk factors and other information relating to the employee. In some embodiments, the machine learning algorithm assigns weights for each risk factor data input, which is applied when determining an overall risk level. In some cases, the machine learning algorithm adjust risk scores based on historical data (e.g., trained data) for a given employee. For example, if in some cases the location indicators identify an employee outside of their employment location for a prolonged period, but the wages still arrive as predicted, the machine learning algorithm may not increase the risk score as significantly (or at all) if an employee is determined to be outside of their employment location for a prolonged period of time. In some case, the Risk module is configured to alert the employee regarding said detection of a risk factor, such that the employee can provide input as to any special considerations (e.g., occasional/routine site visits or other visits that is part of employment but outside of employment location).
In some embodiments, the Risk module is configured to communicate to the EG module the risk score, such that the EG module determines whether to restrict access to earnings.
In some embodiments, the Card module 108 is linked with a card (“Earnings Card”) that is configured to make expenditures based on the funds and the available earnings in the system (e.g., associated with a profile of the employee). In some embodiments, the Earnings Card is configured to be used in the same transactional settings as, for example, a credit card. In some embodiments, the Earnings Card can be used for cash withdrawals, from for example, an ATM machine. In some embodiments, the Earnings Card functions similar to that of a credit card, where earnings accessed (e.g., used) are similar to credit offered by the System (e.g., Earnings tool 100) in advance of receiving wages.
In some embodiments, the amount of expenditures allowed to be made using the Earnings Card is limited to the amount of funds and the available earnings in the system. For example, as expenditures are made, the available earnings and funds in the system are automatically deducted. Accordingly, in some cases, the amount of expenditures by the Earnings Card is backed and/or limited by the total available earnings in the system, and thus the balance will be paid full in each billing period. In some embodiments, the Earnings Card allows for a dynamic credit balance, wherein the credit available is based on the available earnings (e.g., unpaid wages as described herein). In some embodiments, the Card module is configured to report such balances on the Earnings Card and payments to one or more credit bureaus. Accordingly, in some cases, the employee is able to build their credit score through use of the Earnings Card. As used herein, the term “employee” refers to an individual that is able to access available earnings, and wherein said employee is also a customer with respect to using the Earnings Card, as described herein.
As described herein, in some embodiments, disclosed herein are systems and methods for automated funds (money) movement related to a credit card (e.g., “Earnings Card”). In some embodiments, the Earnings Card acts as a partially-secured credit card that incorporates i) a secured credit portion, and/or ii) an unsecured credit portion. In some embodiments, the secured credit portion is based on an amount of funds (money) deposited in a specific “secured” account (Secured account), as required to be deposited by a user, and where such funds may be used as collateral for “credit” extended by the Earnings Card.
In some embodiments, the unsecured credit portion includes earnings (i.e., unpaid wages, as described herein), for which at least a portion may be included as part of the credit limit via the Earnings Card. In some embodiments, the unsecured credit is limited to a certain amount, e.g., a maximum of about $250, $500, $750, $1000, $1500, $2000, $5000, or more, per pay period. In some embodiments, the unsecured credit is limited to a percentage of the user's previous one or more paychecks, such as for example, at most 50%, 60%, 75%, 80%, or 90% of the amount obtained from either a single paycheck, or multiple paychecks. In some embodiments, the unsecured credit is subject to any risk mitigation limits (as described herein). In some embodiments, as described herein, the unsecured credit limit is based on the Earnings tool 100.
In some embodiments, the Earnings Card does not have a pre-set credit limit, but instead, the credit limit automatically adjusts based on the secured credit available (i.e., the amount of funds available in the Secured account) and/or the available earnings (i.e., unpaid wages). In some embodiments, even though the credit limit may fluctuate, it may not be allowed to exceed an upper threshold, such as for example, about $5000, $10000, $15000, or more. In some embodiments, the Earnings Card has a maximum daily spend limit, such as, for example, about $500, $1000, $1500, $2500, $5000, or more. In some embodiments, the Earnings Card has a maximum advance cash limit (e.g., an amount of funds that can be withdrawn, such as from an ATM, via store cash back, etc.), such as, for example, about $100, $200, $300, $500, $1000, or more. As used herein, the Earnings Card may be referred to as a disbursement account, configured to disburse funds to the employee (e.g., based on the amount available in the Secured account and/or the available earnings.
With reference to
In some embodiments, by using such “virtual” accounts, the amount of transfers of “actual” funds may be consolidated. For example, as described herein, the Earning Card may be linked with a financial institution regarding the extension of such credit used by the Earnings Card, and wherein the MM system 200 would be responsible for ensuring the financial system is made whole for such extension of credit via funds collected. Accordingly, rather than transfer funds each time a user, or a collection of users uses the Earnings Card, the MM system 200 may true up for funds owed based on their internal ledger log, and transfer a consolidated amount of “actual” money. In some embodiments, doing a few bulk movements may be much faster and cheaper than trying to use individual automated clearing houses (ACHs) to move funds involving different transactions (e.g., moving a million dollars once a day versus 100 dollars 10,000 times throughout the day).
With continued reference to
In some embodiments, MM system 200 includes the Open Loop/Direct Deposits account 202 is where direct deposits (paychecks) are received from the user's (e.g., employee) employment for time worked. In some embodiments, the MM system 200 further includes virtual account numbers created off of the Direct Deposit account 202, and each user is given their own unique account number, so as to attribute any deposits to this account to the employee (e.g., customer using the Earnings Card). In some embodiments, the sum of the balance of each virtual account is the balance of the actual account (i.e., actual money in the Direct Deposits account 202). In some embodiments, the Direct Deposits account 202 holds funds that the Earnings Card may spend. For example, the portion of the user's paycheck that was not used for expenditures or use of Earnings Card, such as cash outs, and/or was not set aside for other transfers and/or bills (e.g., automatic routing to another account), may be sent to the Secured account 204 (as described herein).
In some embodiments, the MM system 200 is configured to transfer the total amount of the received direct deposits (e.g., paycheck) to the Secured account 204, less any cash outs withdrawn by the user and/or other expenditures (which may include earnings used via the Card module 108). Accordingly, in some embodiments, the Secured account maintains a constant influx of funds being transferred therein, which represents the security credit portion of the Earning Card. For example, if payment is not made for an outstanding balance of the Earnings Card, the amount of funds in the Secured account 204 may be used as collateral. In some embodiments, the MM system 200 can be configured to transfer funds from the Secured account 204 to the Payment account 206 for payment of Earnings Card balances. In some embodiments, the Payment account 206 is similar to the Direct Deposit account 202 in that it has virtual account numbers assigned to it. In some embodiments, each user who has an Earnings Card will be assigned a unique account number from this account. In some embodiments, the MM system 200 is configured to transfer funds into the Payment account 206 in two ways. First, when the user is enrolled in auto-push, wherein, on the day of auto-push runs, money in the Secured account 204 will be moved into the Payment account 206, which can then be used to pay off the Earning Card balance (e.g., for a settled transaction 216). The second way money can come into the Payment account 206 is when a user manually pushes money into the Payment account 206 from another source (e.g., from another account 212 at a financial institution, from an individual, etc.). In some embodiments, such money is automatically pushed into the Payment account 206 from another source (e.g., autopay). In some embodiments, such manual and/or automatic push is considered a user specified payment and will be used to pay off any portion of the Earnings Card balance that is owed. In some embodiments, eligible money received in the Payment account 206 will be moved in bulk (e.g., for a specific customer and/or all customers using the system) once a day, every other day, once a week, or bi-weekly. In some embodiments, money will move out of the Payment account 206 once it becomes eligible to be claimed for the Earnings Card payment (e.g., once a transaction settles 216).
In some embodiments, the funds are configured to be transferred into the Payment account via a pull-based payment, wherein the system initiates transfer of such funds. For example, in some embodiments, based on upon a certain frequency (e.g., bi-weekly, twice a month, etc.), and/or based upon a certain expenditure amount being processed by the Earnings Card, the system is configured to pull a requisite amount of funds from the Secured account 204 and/or an external account (e.g., 212) into the Payment account 206. In some embodiments, such configuration for the system to pull funds into the Payment account requires a pre-authorization by the user for such transfer of funds.
In some embodiments, the Operating account 208 includes the money that is owned by the MM system 200, and any money that may be owed (e.g., to a financial institution) as a result of Earnings Card expenditures. In some embodiments, funds will move into the Operating account 208 from the Payments account 206. In some embodiments, funds in the Operating account is used for multiple purposes executed by the system. For example, in some cases, at least some of the funds in the Operating account stays in this account because it is the interchange portion (e.g., as revenue for the MM system 200 from use of the Earnings Card). In some cases, at least some of the funds will move out to one or more other, different accounts (e.g., Funding account 210) to pay back the money spent for a settled transaction 216 (e.g., by a financial institution), such as for example receivables. In some embodiments, the Funding account pays back such money for transactions that occurred 1 day prior, 2 days prior, 3 days prior, 5 days prior, or 7 days prior. In some cases, at least some of the funds are used by the systems for other expenditures and/or funding resulting from system activities.
In some embodiments, the Funding account 210 is configured to provide the funds to settle 216 a transaction by the Earnings Card. In some embodiments, the Funding account funds are linked to a financial institution. In some embodiments, the Funding account 210 is configured to receive funds from the Operating account 208, or other account. In some embodiments, the Funding account is configured to pay funds to an external account or service provider for receivable issued when the Earnings Card was used (e.g., the Funding account essentially “pays back” the external account or service provider for the receivables that were issued). For example, the Funding account may act as a customer paying back an external account or service provider for settling a transaction that occurred 3 days prior.
With continued reference to
In some embodiments, as described herein, the credit limit 214 of the Earning Card is based on the secured amount 204 and available earnings (via the Earnings tool 100), as described herein. Accordingly, in some embodiments, the MM system 200 is configured to automatically adjust the credit limit based on these amounts. In some embodiments the available earnings may be limited (e.g., per the Card module 108 as described herein). In some embodiments, the credit limit may also have an upper threshold amount, as described herein.
In some embodiments, the user is able to use the Earnings Card for expenditures up to the credit limit. In some embodiments, use of the Earnings Card results in a settled transaction (e.g., the use of the Earnings Card may occur at one point in time, but the transaction is settled when the funds are actually transferred, e.g., when a merchant receives the funds). In some embodiments, the transaction is settled via funds being provided 262 by the Funding account 210, which may be an account owned by another financial institution (e.g., the financial institution linked with the DD account 202). Accordingly, in some embodiments, the financial institution will be owed the funds used to settle each transaction.
In some embodiments, the MM system 200 is configured to determine the total amount of all the settled transactions, which is at least partially what a balance due for the Earnings Card is based off. In some embodiments, the MM system 200 is configured to allow the user to periodically send funds (256 and/or 264) from the Secured Account and/or from the External Account 212 to the Payment account (e.g., once or more times a month). In some embodiments, funds are transferred (256 and/or 264) once a month, corresponding to a deadline to pay a monthly bill for the Earnings Card. In some embodiments, funds are transferred 256 bi-weekly or twice a month.
In some embodiments, the MM system 200 is configured to allow the user to send payments 264 from an external account (e.g., from another account at the Financial Institution and/or a different financial institution). In some embodiments, such payments 264 can occur periodically (automatically, such as bi-weekly or twice a month), or manually (initiated by the user).
In some embodiments, the Payment account is configured to transfer funds 258 to the Operating account, which is linked to the MM system 200. In some embodiments, the MM system 200 is configured to transfer funds 260 from the Operating account to the Funding account, so as to pay back funds provided 262 by the financial institution in settling a transaction (e.g., so as to purchase the Earnings Card receivables [e.g., similar to credit card receivables] after the transaction settles). In some embodiments, such pay back of funds (e.g., purchase of Earnings Card receivables) occurs in bulk, such as once per day, once every other day, once a week, bi-weekly, or twice a week. In some embodiments, such bulk purchase of receivables refers to all transactions settled for the given time period (e.g., for the previous day, the day of, previous two days, etc.), wherein the transactions refer to all transactions by a single employee, or by all users of the system.
As described herein, one or more of said aforementioned steps may be automated. In some embodiments, the MM system 200 is configured to ensure the movement of funds is sequential so as to help ensure an attempt by one account to send funds before receiving a required amount of funds does not occur.
The system and methods described herein, including the system for determining available earnings for an employee, including verification of employment status, are, in some embodiments, performed on one or more computers.
For example, the building and deployment of any system described herein can be implemented in hardware or software, or a combination of both. In one embodiment, a machine-readable storage medium is provided, the medium comprising a data storage material encoded with machine readable data which, when using a machine programmed with instructions for using said data, is capable of executing any one of the methods described herein and/or displaying any of the datasets or results (e.g., available earnings, employment status, employment stability) described herein. Some embodiments can be implemented in computer programs executing on programmable computers, comprising a processor and a data storage system (including volatile and non-volatile memory and/or storage elements), and optionally including a graphics adapter, a pointing device, a network adapter, at least one input device, and/or at least one output device. A display may be coupled to the graphics adapter. Program code is applied to input data to perform the functions described above and generate output information. The output information is applied to one or more output devices, in known fashion. The computer can be, for example, a personal computer, microcomputer, or workstation of conventional design.
Each program can be implemented in a high-level procedural or object-oriented programming language to communicate with a computer system. However, the programs can be implemented in assembly or machine language, if desired. In any case, the language can be a compiled or interpreted language. Each such computer program is preferably stored on a storage media or device (e.g., ROM or magnetic diskette) readable by a general or special purpose programmable computer, for configuring and operating the computer when the storage media or device is read by the computer to perform the procedures described herein. The system can also be considered to be implemented as a computer-readable storage medium, configured with a computer program, where the storage medium so configured causes a computer to operate in a specific and predefined manner to perform the functions described herein.
The signature patterns and databases thereof can be provided in a variety of media to facilitate their use. “Media” refers to a manufacture that contains the signature pattern information of an embodiment. The databases of some embodiments can be recorded on computer readable media, e.g., any medium that can be read and accessed directly by a computer. Such media include, but are not limited to: magnetic storage media, such as floppy discs, hard disc storage medium, and magnetic tape; optical storage media such as CD-ROM; electrical storage media such as RAM and ROM; and hybrids of these categories such as magnetic/optical storage media. One of skill in the art can readily appreciate how any of the presently known computer readable mediums can be used to create a manufacture comprising a recording of the present database information. “Recorded” refers to a process for storing information on computer readable medium, using any such methods as known in the art. Any convenient data storage structure can be chosen, based on the means used to access the stored information. A variety of data processor programs and formats can be used for storage, e.g., word processing text file, database format, etc.
In some embodiments, the systems and methods described herein, including the systems and methods for determining available earnings and employment status, are performed on one or more computers in a distributed computing system environment (e.g., in a cloud computing environment). In this description, “cloud computing” is defined as a model for enabling on-demand network access to a shared set of configurable computing resources. Cloud computing can be employed to offer on-demand access to the shared set of configurable computing resources. The shared set of configurable computing resources can be rapidly provisioned via virtualization and released with low management effort or service provider interaction, and then scaled accordingly. A cloud-computing model can be composed of various characteristics such as, for example, on-demand self-service, broad network access, resource pooling, rapid elasticity, measured service, and so forth. A cloud-computing model can also expose various service models, such as, for example, Software as a Service (“SaaS”), Platform as a Service (“PaaS”), and Infrastructure as a Service (“IaaS”). A cloud-computing model can also be deployed using different deployment models such as private cloud, community cloud, public cloud, hybrid cloud, and so forth. In this description and in the claims, a “cloud-computing environment” is an environment in which cloud computing is employed.
The storage device 408 is a non-transitory computer-readable storage medium such as a hard drive, compact disk read-only memory (CD-ROM), DVD, or a solid-state memory device. The memory 406 holds instructions and data used by the processor 402. The input interface 414 is a touch-screen interface, a mouse, track ball, or other type of pointing device, a keyboard, or some combination thereof, and is used to input data into the computer 400. In some embodiments, the computer 400 may be configured to receive input (e.g., commands) from the input interface 414 via gestures from the user. The network adapter 416 couples the computer 400 to one or more computer networks.
The graphics adapter 412 displays images and other information on the display 418. In various embodiments, the display 418 is configured such that the user may (e.g., employee, personnel associated with system) may input user selections on the display 418 to, for example, initiate the system for determining available earnings and/or employment status. In one embodiment, the display 418 may include a touch interface. In various embodiments, the display 418 can show available earnings and funds associated with a profile of the employee.
The computer 400 is adapted to execute computer program modules for providing functionality described herein. As used herein, the term “module” refers to computer program logic used to provide the specified functionality. Thus, a module can be implemented in hardware, firmware, and/or software. In one embodiment, program modules are stored on the storage device 408, loaded into the memory 406, and executed by the processor 402.
The types of computers 400 used by the entities of
In some embodiments, the processor applies one or more algorithms to predict an employment status of a user, and whether they will receive a next paycheck (as described herein). In some embodiments, each algorithm may correspond to determining whether a next paycheck will be received for a given number of parameters associated with the user (as described herein). In some embodiments, the one or more processors apply algorithms (e.g., algorithms embodied in trained models) to correlate the various combinations of parameters associated with the user and/or employment (as described herein). In some embodiments, at least one of the one or more algorithms may comprise a machine learning algorithm incorporating artificial intelligence (AI) to help determine whether a next paycheck will be received, as described herein. For example, in some embodiments, said artificial intelligence is applied to trained model data (which may be included in the decision engine data) and optionally existing user data (such as historical data correlating parameters, such as those exemplified in
In some embodiments, any one of the decision engine(s) described herein is any one of a regression model (e.g., linear regression, logistic regression, or polynomial regression), decision tree, random forest, gradient boosted machine learning model, support vector machine, Naïve Bayes model, k-means cluster, or neural network (e.g., feed-forward networks, convolutional neural networks (CNN), deep neural networks (DNN), autoencoder neural networks, generative adversarial networks, or recurrent networks (e.g., long short-term memory networks (LSTM), bi-directional recurrent networks, deep bi-directional recurrent networks), or any combination thereof. In particular embodiments, any one of the decision engine(s) described herein is a logistic regression model. In particular embodiments, any one of the decision engine(s) described herein is a random forest classifier. In particular embodiments, any one of the decision engine(s) described herein is a gradient boosting model.
In some embodiments, any one of the decision engine(s) described herein (e.g., a trained model) can be trained using a machine learning implemented method, such as any one of a linear regression algorithm, logistic regression algorithm, decision tree algorithm, support vector machine classification, Naïve Bayes classification, K-Nearest Neighbor classification, random forest algorithm, deep learning algorithm, gradient boosting algorithm, and dimensionality reduction techniques such as manifold learning, principal component analysis, factor analysis, autoencoder regularization, and independent component analysis, or combinations thereof. In particular embodiments, the machine learning implemented method is a logistic regression algorithm. In particular embodiments, the machine learning implemented method is a random forest algorithm. In particular embodiments, the machine learning implemented method is a gradient boosting algorithm, such as XGboost. In some embodiments, any one of the trained model(s) described herein is trained using supervised learning algorithms, unsupervised learning algorithms, semi-supervised learning algorithms (e.g., partial supervision), weak supervision, transfer, multi-task learning, or any combination thereof.
In some embodiments, any one of the trained model(s) described herein has one or more parameters, such as hyperparameters or model parameters. Hyperparameters are generally established prior to training. Examples of hyperparameters include the learning rate, depth or leaves of a decision tree, number of hidden layers in a deep neural network, number of clusters in a k-means cluster, penalty in a regression model, and a regularization parameter associated with a cost function. Model parameters are generally adjusted during training. Examples of model parameters include weights associated with nodes in layers of neural network, support vectors in a support vector machine, node values in a decision tree, and coefficients in a regression model.
In some embodiments, any one of the trained model(s) described herein are trained via training data located in the trained model data (which may be in communication with the processor 108).
In various embodiments, the training data used for training any one of the trained model(s) described herein includes reference ground truths that indicate one or more press conditions associated with a desired press cut(s) (hereafter also referred to as “positive” or “+”) or whether one or more press conditions were not associated with a desired press cut(s) (hereafter also referred to as “negative” or “−”). In various embodiments, the reference ground truths in the training data are binary values, such as “1” or “0.” For example, one or more parameters associated with a next paycheck received status can be identified in the training data with a value of “1” whereas one or more parameters not associated with a next paycheck received status can be identified in the training data with a value of “0.” In various embodiments, any one of the trained model(s) described herein are trained using the training data to minimize a loss function such that any one of the trained model(s) described herein can better predict the outcome (e.g., quality of press cuts) based on the input (e.g., one or more press conditions, characteristics of a juice, etc.). In some embodiments, the loss function is constructed for any of a least absolute shrinkage and selection operator (LASSO) regression, Ridge regression, or ElasticNet regression. In some embodiments, any one of the trained model(s) described herein is a random forest model, and is trained to minimize one of Gini impurity or Entropy metrics for feature splitting, thereby enabling any one of the trained model(s) described herein to better predict whether a user will receive a next paycheck.
In some embodiments, historical data relating to users, parameters and whether a next paycheck was received, as obtained via the system 100 is stored in the computing system (e.g., see
Disclosed herein, in some aspects, is a system for disbursing advanced wages to an employee prior to a payment date of scheduled wages for a pay period, the system comprising one or more processors; and one or more memories storing instructions that, when executed by the one or more processors, cause the system to perform operations including: identifying a predictable pattern for i) the amount of scheduled wages received by the employee, ii) the frequency of the scheduled wages received, iii) a rate at which the scheduled wages are accrued during the pay period (“pay rate”), or iv) a combination thereof; calculating an amount of advanced wages available (“max advanced wages”) for disbursement to the employee, the max advanced wages based on i) the cumulative time worked by the employee during the pay period, ii) the predictable pattern, iii) expenditures by the employee, iv) a threshold percentage of the predicted pattern amount of the scheduled wages, v) a threshold amount, or vi) a combination thereof; and automatically directing a flow of funds between two or more financial accounts associated with the system (“system accounts”), so as to provide a safeguard for a disbursement account used to disburse advanced wages to the employee, wherein the system is configured to set a limit of an amount available to be disbursed by the disbursement account (“disbursement limit”) based at least partially on the max advanced wages; wherein any one of the one or more processors is configured to be in communication with one or more financial accounts associated with the employee (“employee account”), the two or more system accounts, the disbursement account, or any combination thereof, so as to perform operations from one or more of (a)-(c).
In some embodiments, the one or more processors is configured to automatically adjust the disbursement limit based on the time worked by the employee during the pay period. In some embodiments, the disbursement limit has a maximum threshold amount and/or a maximum percentage of the predicted pattern amount of the scheduled wages. In some embodiments, the maximum threshold amount is about $250, $500, $1000, $2000, or $5000. In some embodiments, the maximum percentage is at most 50%, 60%, 75%, or 90% of the predicted pattern amount of the scheduled wages.
In some embodiments, the two or more system accounts comprise a direct deposit account, a secured account, and a payment account. In some embodiments, the direct deposit account is configured to receive at least a portion of an amount of the scheduled wages, wherein the one or more processors is configured to automatically transfer from the direct deposit account any disbursement of advanced wages to an operating account configured to enable disbursement of said advanced wages. In some embodiments, the one or more processors is configured to automatically transfer to the secured account at least some of the amount of the scheduled wages received by the direct deposit account, such that the disbursement limit is based at least partially on i) the max advanced wages, and ii) an amount of funds in the secured account (“secured funds”), and wherein the disbursement limit is automatically adjusted based on changes to the max advanced wages and secured funds. In some embodiments, when the disbursement account disburses an amount of funds exceeding the max advanced wages, the one or more processors is configured to transfer at least a portion of the secured funds to the payment account to facilitate pay back of such excess amount. In some embodiments, the one or more processors is configured to automatically transfer the at least a portion of the secured funds to the payment account according to a first prescribed frequency. In some embodiments, the first prescribed frequency is daily, every other day, bi-weekly, twice a month, or monthly. In some embodiments, the employee account is configured to automatically transfer funds to the payment account according to a second prescribed frequency. In some embodiments, the second prescribed frequency is daily, every other day, bi-weekly, twice a month, or monthly.
In some embodiments, the one or more processors is configured to automatically transfer funds between the two or more system accounts in a sequential manner so as to reduce a risk of the disbursement limit being met and/or the disbursement limit being maintained, thereby rendering the disbursement account unable to disburse any additional funds to the employee. In some embodiments, the operations further include verifying an employment status of the employee during the pay period, the employment status corresponding to an active status or an inactive status, wherein an active status corresponds a prediction of the employee receiving the next scheduled wages, and an inactive status corresponds to a prediction of the employee not receiving the next scheduled wages. In some embodiments, verifying the employment status comprises predicting whether the employee will receive a next scheduled wages using a first decision engine by the one or more processors, wherein an active status corresponds to an employee receiving the next scheduled wages. In some embodiments, the first decision engine comprises a trained model, a decision tree, an analytical expression, or a combination thereof. In some embodiments, the first decision engine applies one or more employment status data for the employee, the employment status data comprising past scheduled wages data, past employee financial activities data, past disbursed advanced wages data, past restore faults data, or a combination thereof, to predict whether the employee will receive the next scheduled wages. In some embodiments, the first decision engine applies the one or more employments status data using a machine learning model. In some embodiments, the machine learning model incorporates a respective weight for each type of employment status data, wherein each respective weight is determined using trained data of historical employment status data relating to the employee, from a cohort of individuals, or both, wherein each data input is correlated with whether i) the respective individual of the cohort of individuals, or ii) employee, received scheduled wages for a given pay period.
In some embodiments, past scheduled wages data comprises receipt of on-time scheduled wages, missing scheduled wages, the amount of scheduled wages with respect to the predicted pattern amount, or any combination thereof. In some embodiments, past employee financial activities comprises transactions at a financial account associated with the employee, spending by the employee, or both. In some embodiments, the operations further include performing an employment status prediction at the beginning of each pay period. In some embodiments, the one or more processors is further configured to send an alert to the employee, a system administrator, or both, if the employee is predicted not to received the next scheduled wages.
In some embodiments, verifying the employment status comprises determining an employee risk level using a second decision engine by the one or more processors. In some embodiments, a high risk level correlates with a low likelihood of the employee receiving the scheduled wages and an inactive status, and a low risk level correlates with a high likelihood of the employee receiving the scheduled wages and an active status. In some embodiments, the second decision engine applies one or more risk factors data comprising transactions at the employee account data, past verifications of the employee email account data, past verifications of the location of the employee data, past restore faults data, income stability data, past employment inactive status data, or a combination thereof, to determine an employee risk level. In some embodiments, the second decision engine applies the one or more risk factors data using a machine learning model. In some embodiments, the machine learning model incorporates a respective weight for each type of risk factor data, wherein each respective weight is determined using trained data of historical risk factor data relating to the employee, wherein each data input is correlated with whether the employee received the scheduled wages for a given pay period.
Disclosed herein, in other aspects, is a non-transitory computer readable medium for disbursing advanced wages to an employee prior to a payment date of scheduled wages for a pay period, the non-transitory computer readable medium comprising instructions that, when executed by a processor, cause the processor to perform operations including: identifying a predictable pattern for i) the amount of scheduled wages received by the employee, ii) the frequency of the scheduled wages received, iii) a rate at which the scheduled wages are accrued during the pay period (“pay rate”), or iv) a combination thereof; calculating an amount of advanced wages available (“max advanced wages”) for disbursement to the employee, the max advanced wages based on i) the cumulative time worked by the employee during the pay period, ii) the predictable pattern, iii) expenditures by the employee, iv) a threshold percentage of the predicted pattern amount of the scheduled wages, v) a threshold amount, or vi) a combination thereof; and automatically directing a flow of funds between two or more financial accounts associated with a system (“system accounts”), so as to provide a safeguard for a disbursement account used to disburse advanced wages to the employee, wherein the processor is configured to set a limit of an amount available to be disbursed by the disbursement account (“disbursement limit”) based at least partially on the max advanced wages; wherein the processor is configured to be in communication with one or more financial accounts associated with the employee (“employee account”), the two or more system accounts, the disbursement account, or any combination thereof, so as to perform operations from one or more of (a)-(c).
In some embodiments, the processor is configured to automatically adjust the disbursement limit based on the time worked by the employee during the pay period. In some embodiments, the disbursement limit has a maximum threshold amount and/or a maximum percentage of the predicted pattern amount of the scheduled wages. In some embodiments, the maximum threshold amount is about $250, $500, $1000, $2000, or $5000. In some embodiments, the maximum percentage is at most 50%, 60%, 75%, or 90% of the predicted pattern amount of the scheduled wages.
In some embodiments, the two or more system accounts comprise a direct deposit account, a secured account, and a payment account. In some embodiments, the direct deposit account is configured to receive at least a portion of an amount of the scheduled wages, wherein the processor is configured to automatically transfer from the direct deposit account any disbursement of advanced wages to an operating account configured to enable disbursement of said advanced wages. In some embodiments, the processor is configured to automatically transfer to the secured account at least some of the amount of the scheduled wages received by the direct deposit account, such that the disbursement limit is based at least partially on i) the max advanced wages, and ii) an amount of funds in the secured account (“secured funds”), and wherein the disbursement limit is automatically adjusted based on changes to the max advanced wages and secured funds. In some embodiments, when the disbursement account disburses an amount of funds exceeding the max advanced wages, the processor is configured to transfer at least a portion of the secured funds to the payment account to facilitate pay back of such excess amount. In some embodiments, the processor is configured to automatically transfer the at least a portion of the secured funds to the payment account according to a first prescribed frequency. In some embodiments, the first prescribed frequency is daily, every other day, bi-weekly, twice a month, or monthly. In some embodiments, the employee account is configured to automatically transfer funds to the payment account according to a second prescribed frequency. In some embodiments, the second prescribed frequency is daily, every other day, bi-weekly, twice a month, or monthly.
In some embodiments, the processor is configured to automatically transfer funds between the two or more system accounts in a sequential manner so as to reduce a risk of the disbursement limit being met and/or the disbursement limit being maintained, thereby rendering the disbursement account unable to disburse any additional funds to the employee.
In some embodiments, the operations further include verifying an employment status of the employee during the pay period, the employment status corresponding to an active status or an inactive status, wherein an active status corresponds a prediction of the employee receiving the next scheduled wages, and an inactive status corresponds to a prediction of the employee not receiving the next scheduled wages. In some embodiments, verifying the employment status comprises predicting whether the employee will receive a next scheduled wages using a first decision engine by the processor, wherein an active status corresponds to an employee receiving the next scheduled wages. In some embodiments, the first decision engine comprises a trained model, a decision tree, an analytical expression, or a combination thereof. In some embodiments, the first decision engine applies one or more employment status data for the employee, the employment status data comprising past scheduled wages data, past employee financial activities data, past disbursed advanced wages data, past restore faults data, or a combination thereof, to predict whether the employee will receive the next scheduled wages. In some embodiments, the first decision engine applies the one or more employments status data using a machine learning model. In some embodiments, the machine learning model incorporates a respective weight for each type of employment status data, wherein each respective weight is determined using trained data of historical employment status data relating to the employee, from a cohort of individuals, or both, wherein each data input is correlated with whether i) the respective individual of the cohort of individuals, or ii) employee, received scheduled wages for a given pay period.
In some embodiments, past scheduled wages data comprises receipt of on-time scheduled wages, missing scheduled wages, the amount of scheduled wages with respect to the predicted pattern amount, or any combination thereof. In some embodiments, past employee financial activities comprises transactions at a financial account associated with the employee, spending by the employee, or both. In some embodiments, the operations further include performing an employment status prediction at the beginning of each pay period. In some embodiments, the processor is further configured to send an alert to the employee, a system administrator, or both, if the employee is predicted not to received the next scheduled wages.
In some embodiments, verifying the employment status comprises determining an employee risk level using a second decision engine by the processor.
The non-transitory computer readable medium of claim 54, wherein a high risk level correlates with a low likelihood of the employee receiving the scheduled wages and an inactive status, and a low risk level correlates with a high likelihood of the employee receiving the scheduled wages and an active status. In some embodiments, the second decision engine applies one or more risk factors data comprising transactions at the employee account data, past verifications of the employee email account data, past verifications of the location of the employee data, past restore faults data, income stability data, past employment inactive status data, or a combination thereof, to determine an employee risk level. In some embodiments, the second decision engine applies the one or more risk factors data using a machine learning model. In some embodiments, the machine learning model incorporates a respective weight for each type of risk factor data, wherein each respective weight is determined using trained data of historical risk factor data relating to the employee, wherein each data input is correlated with whether the employee received the scheduled wages for a given pay period.
Disclosed herein, in other aspects, is a method for disbursing advanced wages to an employee prior to a payment date of scheduled wages for a pay period, the method comprising: identifying a predictable pattern for i) the amount of scheduled wages received by the employee, ii) the frequency of the scheduled wages received, iii) a rate at which the scheduled wages are accrued during the pay period (“pay rate”), or iv) a combination thereof; calculating an amount of advanced wages available (“max advanced wages”) for disbursement to the employee, the max advanced wages based on i) the cumulative time worked by the employee during the pay period, ii) the predictable pattern, iii) expenditures by the employee, iv) a threshold percentage of the predicted pattern amount of the scheduled wages, v) a threshold amount, or vi) a combination thereof; and automatically directing a flow of funds between two or more financial accounts associated with a system (“system accounts”), so as to provide a safeguard for a disbursement account used to disburse advanced wages to the employee, wherein the a limit of an amount available to be disbursed by the disbursement account (“disbursement limit”) is based at least partially on the max advanced wages.
In some embodiments, the disbursement limit is automatically adjusted based on the time worked by the employee during the pay period. In some embodiments, the disbursement limit has a maximum threshold amount and/or a maximum percentage of the predicted pattern amount of the scheduled wages. In some embodiments, the maximum threshold amount is about $250, $500, $1000, $2000, or $5000. In some embodiments, the maximum percentage is at most 50%, 60%, 75%, or 90% of the predicted pattern amount of the scheduled wages.
In some embodiments, the two or more system accounts comprise a direct deposit account, a secured account, and a payment account. In some embodiments, the direct deposit account is configured to receive at least a portion of an amount of the scheduled wages, wherein any disbursement of advanced wages is configured to be automatically transferred from the direct deposit account to an operating account configured to enable disbursement of said advanced wages. In some embodiments, at least some of the amount of the scheduled wages received by the direct deposit account is configured to be automatically transferred to the secured account, such that the disbursement limit is based at least partially on i) the max advanced wages, and ii) an amount of funds in the secured account (“secured funds”), and wherein the disbursement limit is automatically adjusted based on changes to the max advanced wages and secured funds. In some embodiments, when the disbursement account disburses an amount of funds exceeding the max advanced wages, at least a portion of the secured funds is configured to be transferred to the payment account to facilitate pay back of such excess amount. In some embodiments, the at least a portion of the secured funds is configured to be automatically transferred to the payment account according to a first prescribed frequency. In some embodiments, the first prescribed frequency is daily, every other day, bi-weekly, twice a month, or monthly. In some embodiments, the employee account is configured to automatically transfer funds to the payment account according to a second prescribed frequency. In some embodiments, the second prescribed frequency is daily, every other day, bi-weekly, twice a month, or monthly.
In some embodiments, funds between the two or more system accounts is configured to be automatically transferred in a sequential manner so as to reduce a risk of the disbursement limit being met and/or the disbursement limit being maintained, thereby rendering the disbursement account unable to disburse any additional funds to the employee.
In some embodiments, the method comprises verifying an employment status of the employee during the pay period, the employment status corresponding to an active status or an inactive status, wherein an active status corresponds a prediction of the employee receiving the next scheduled wages, and an inactive status corresponds to a prediction of the employee not receiving the next scheduled wages. In some embodiments, verifying the employment status comprises predicting whether the employee will receive a next scheduled wages using a first decision engine, wherein an active status corresponds to an employee receiving the next scheduled wages. In some embodiments, the first decision engine comprises a trained model, a decision tree, an analytical expression, or a combination thereof. In some embodiments, the first decision engine applies one or more employment status data for the employee, the employment status data comprising past scheduled wages data, past employee financial activities data, past disbursed advanced wages data, past restore faults data, or a combination thereof, to predict whether the employee will receive the next scheduled wages. In some embodiments, the first decision engine applies the one or more employments status data using a machine learning model. In some embodiments, the machine learning model incorporates a respective weight for each type of employment status data, wherein each respective weight is determined using trained data of historical employment status data relating to the employee, from a cohort of individuals, or both, wherein each data input is correlated with whether i) the respective individual of the cohort of individuals, or ii) employee, received scheduled wages for a given pay period.
In some embodiments, past scheduled wages data comprises receipt of on-time scheduled wages, missing scheduled wages, the amount of scheduled wages with respect to the predicted pattern amount, or any combination thereof. In some embodiments, past employee financial activities comprises transactions at a financial account associated with the employee, spending by the employee, or both. In some embodiments, the method further comprises performing an employment status prediction at the beginning of each pay period. In some embodiments, the method further comprises sending an alert to the employee, a system administrator, or both, if the employee is predicted not to received the next scheduled wages.
In some embodiments, verifying the employment status comprises determining an employee risk level using a second decision engine. In some embodiments, a high risk level correlates with a low likelihood of the employee receiving the scheduled wages and an inactive status, and a low risk level correlates with a high likelihood of the employee receiving the scheduled wages and an active status. In some embodiments, the second decision engine applies one or more risk factors data comprising transactions at the employee account data, past verifications of the employee email account data, past verifications of the location of the employee data, past restore faults data, income stability data, past employment inactive status data, or a combination thereof, to determine an employee risk level. In some embodiments, the second decision engine applies the one or more risk factors data using a machine learning model. In some embodiments, the machine learning model incorporates a respective weight for each type of risk factor data, wherein each respective weight is determined using trained data of historical risk factor data relating to the employee, wherein each data input is correlated with whether the employee received the scheduled wages for a given pay period.
All publications, patents, patent applications and other documents cited in this application are hereby incorporated by reference herein in their entirety for all purposes to the same extent as if each individual publication, patent, patent application or other document were individually indicated to be incorporated by reference for all purposes.
While various specific embodiments have been illustrated and described, the above specification is not restrictive. It will be appreciated that various changes can be made without departing from the spirit and scope of the present disclosure(s). Many variations will become apparent to those skilled in the art upon review of this specification.
This application claims the benefit of and priority to U.S. Patent Application No. 63/421,518, titled “System and Method for Providing Advance Access to Unpaid Wages”, and filed Nov. 1, 2022; to U.S. Patent Application No. 63/421,519, titled “System and Method for Accessing Unpaid Wages”, and filed Nov. 1, 2022; and to U.S. Patent Application No. 63/421,515, titled “System and Method for Automatic Routing of Wages”, and filed Nov. 1, 2022; each of which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| 63421518 | Nov 2022 | US | |
| 63421519 | Nov 2022 | US | |
| 63421515 | Nov 2022 | US |
