Alarm management system with real-time remediation function and integrated with overdraft limit initiating system

Abstract

Embodiments provide an alarm management and real-time remediation system that receives an electronic file that includes an overdraft information data structure that includes overdraft information, and automatically parses the overdraft information as an overdraft event for an associated customer. And the system sends an overdraft limit notification message to the associated customer. The message includes a link to an authentication interface of an institution associated with the customer. After the customer is authenticated, the system provides a user interface that displays overdraft information for each overdraft event associated with the customer, and display elements for payment options. In response to the customer selecting the payment option, the system sends a payment message that results in a transfer to the institution.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

[0002] This application claims the benefit of U.S. Patent Application No. 17 / 860,611, filed on July 8, 2022, the entire contents of which are incorporated herein by reference.

[0003] This application is related to U.S. Patent Publication No. US 2015 / 0026060A1 [Abandoned], filed on July 7, 2014, entitled “FINANCIAL ALERT MANAGEMENT SYSTEM HAVING A MOBILE INTERFACE,” the entire contents of which are incorporated herein by reference.

[0004] This application is also related to U.S. Patent No. US11,144,917B1, entitled “ALERT MANAGEMENT SYSTEM WITH REAL-TIME REMEDIATION AND INTEGRATION WITH THE EXCEPTION ORIGINATING SYSTEM,” issued on October 12, 2021, the entire contents of which are incorporated herein by reference. Technical Field

[0005] The present invention relates to a technology platform for real-time management of time-sensitive exception notifications and integration with an overdraft facility initiation system. Background Art

[0006] There are a variety of techniques for providing alerts to users. The existing techniques suffer from various technical problems and other deficiencies. In many cases, these techniques provide alerts but lack a technical mechanism for enabling users to take action. In other cases involving multiple parties, the techniques are deficient because it does not enable users to take action or provide the necessary real-time updates to the systems of all parties involved. In some cases, when entities have limited access to their servers and / or other computer systems, it may be necessary to manually notify users of the actions. This is a technical limitation, especially when there is a time-sensitive need for users to receive alerts, take action on the alerts, and have entities with limited system access updated on the actions. Typically, existing systems include manually notifying these entities, but such notifications are ineffective due to time-sensitive deadlines. These and other technical problems exist.

[0007] Alert management systems are applicable to many industries and many practical applications. Without limiting, one practical application involves various fintech solutions. In particular, various technologies exist to facilitate notifying customers of actions that need to be taken on financial or other accounts. These technologies suffer from the above-mentioned and other shortcomings. In addition, the technical shortcomings of existing systems in the fintech field are exacerbated by some regulatory issues, system complexity, and the multiple parties involved in the system. Multiple examples exist in this regard.

[0008] As just one example, the following explains the technical and other implications of what happens when a negotiable instrument (such as a check or ACH withdrawal) is not honored by the financial institution associated with the account on which the negotiable instrument was issued (i.e., the payee bank).

[0009] A negotiable instrument may be generated, but the financial institution associated with the account on which the negotiable instrument was drawn (i.e., the drawee bank) may not be able to honor the instrument for a number of different reasons. One reason may be that insufficient funds are available in the account on which the negotiable instrument is attempted to be drawn. This is often referred to as a Non-Sufficient Funds (NSF) event. Similarly, situations where funds deposited into an account have not yet been received (i.e., funds are not available) are often referred to as Uncollected Funds (UCF) events. Throughout this note, both NSF events and UCF events will be referred to as Non-Sufficient Funds (NSF) events unless otherwise specified.

[0010] Insufficient funds (i.e., insufficient funds) may be due to an account being overdrawn (i.e., an overdraft has occurred and the amount of money withdrawn from the account has resulted in an available balance in the account of less than zero) or because the amount listed on the negotiable instrument exceeds the available balance in the account, even if that balance is greater than zero but less than the amount listed on the negotiable instrument. Because checks, money orders, substitute checks, and ACH withdrawals are negotiable instruments that are processed using regular clearing methods, while other transactions (such as ATM withdrawals, cashing of in-bank checks and money orders, and point-of-sale transactions) are approved and cleared at the time of the transaction, the financial institution associated with the account may refuse to pay the negotiable instrument (in this example, a non-preauthorized withdrawal request) and return the negotiable instrument as unpaid.

[0011] Unfortunately, although the payee's financial institution may refuse to honor a negotiable instrument due to insufficient or unavailable funds, the reality is that if the holder of the negotiable instrument (i.e., the payee) does not personally cash the negotiable instrument at the payee's financial institution, but deposits the check into his account at another financial institution (i.e., the payee's account), the payee's financial institution may automatically pay / credit the amount listed on the negotiable instrument to the payee's account through overnight processing. Then, only after the payee's financial institution performs the clearing process, the payee's financial institution will be informed that the negotiable instrument actually caused a insufficient funds event (also known as a NSF occurrence).

[0012] On the payee side, the payee's financial institution will generate and issue a non-sufficient funds notice. Once the payee's financial institution returns the instrument as a returned check document, the payee's financial institution will reimburse the amount received minus the fees incurred for assuming the risk. In addition, the payee's financial institution will not honor the negotiable instrument and send the payee an NSF notice via first class mail, with an additional fee for issuing a "bad" negotiable instrument.

[0013] On the payee side, the payee receives a Returned Deposit Instrument (RDI) notice and is often charged a negotiable instrument fee by its financial institution. In addition, the payee may have issued a negotiable instrument against the payee’s negotiable instrument, creating a snowball effect of bad instruments.

[0014] At this point, the payee is solely responsible for recovering from the payee the unpaid amount listed on the negotiable instrument and any associated penalties, fees and charges. This may result in the payee taking legal action against the payee. In addition, the payee's financial institution may also report the payee to a database of bad check issuers, such as CheckConnection, TeleCheck, Shared Check Authorization Network ("SCAN"), or ChexSystems. Finally, in most states, intentionally writing a "bad check" is a crime and will result in varying degrees of criminal penalties.

[0015] Each business day, each time a depository financial institution reconciles an account with the corresponding negotiable instruments received on the previous business day, an exception information (EI) is generated. The EI can identify all transactions submitted on the previous day that resulted in insufficient funds, or only the items that resulted in insufficient balances. Typically, for each NSF occurrence, the EI will contain information about the corresponding account and the corresponding account holder. Each financial institution may also mark items that trigger overdrafts / courtesy pays. In the following description, each EI may be accompanied by information marking the items that trigger overdrafts / courtesy pays.

[0016] In order to better understand the above issues, we refer to Figure 1 Describe the problem in detail. Figure 11 is a block diagram of an example of an implementation of a known method of making a payment between two persons using a transferable instrument 100. The transferable instrument 100 may be any type of transaction check, automated clearing house (ACH) transaction, point of sale transaction, money order, or similar transferable instrument. In this example, a first person is a payee 102 and a second person is a payee 104. The payee 102 has a payee account 106 at a payee financial institution (FI) 108. The payee 104 has a payee account 110 at a payee FI 112. In this example, the payee FI 108 and the payee FI 112 are in signal communication with each other via a signal path 114, which may include any known communication network 116. The communication network 116 may be a computer network (e.g., the Internet), or a proprietary secure network. The signal path 114 between the payer FI 108 and the payee FI 112 may include a payer computer server 118 (located at the payer FI 108) and a payee computer server 120 (located at the payee FI 112). The payer 102, the payee 104, or both may be business entities or individuals. The payer account 106, the payee account 110, or both may be checking accounts. The communication network 116 may communicate signals with a regional Federal Reserve Bank 117.

[0017] In one example of operation, a payee 102 generates 122 a negotiable instrument 100 listing a monetary amount and delivers it to a payee 104, either physically or electronically. In this example, the negotiable instrument 100 is drawn from a payee account 106, so the payee 102 is the "drawee" of the payee account 106, and the payee FI 108 is the "drawee" because the payee FI 108 is where the negotiable instrument 100 can be presented for payment from the payee account 106. The payee 104 deposits the negotiable instrument 100 into a payee account 110, either physically or electronically. Once the negotiable instrument 100 is deposited into the payee account 110, the payee FI 112 may present the negotiable instrument 100 to the payee FI 108 for payment via a signal path 114 including a communications network 116. In response, the payee FI 108 sends a payment 132 for the monetary amount listed on the negotiable instrument 100 via the payee computer server 118. The payee FI 108 may use the Check 21 system or other inter-bank transaction system.

[0018] In this example, once the payee FI 108 sends the payment 132 to the payee FI 112, the payee FI 108 withdraws funds from the payee account 106 and determines whether there are sufficient funds in the payee account 106 to pay the amount listed on the negotiable instrument 100. If there are sufficient funds in the payee account 106, the amount listed on the negotiable instrument 100 is withdrawn from the payee account 106 to complete the payment 132 made by the payee FI 108. Conversely, if the payee FI 108 determines that there are insufficient funds in the payee account 106 to pay the amount listed on the negotiable instrument 100, the clearing process will mark the negotiable instrument 100 as causing NSF to occur and then place it as an NSF item on the exception information (EI) that the payee FI 108 will generate the next day. In this example, the clearing process can be performed by a computer system, such as a reconciliation system 134. The reconciliation system 134 may optionally be part of the payer server 118, or may also be another independent computer system of the payer FI 108. The reconciliation system 134 may include software including rules and decision engines / modules for reconciling the amount paid on behalf of the payer 102 with the available funds in the payer account 106. The reconciliation system 134 may access the customer list and corresponding accounts of the payer FI 108, so that a daily EI 136 may be generated, which includes all submitted items that cause insufficient balances or all NSF occurrences and their corresponding negotiable instruments that cause NSF occurrences, the corresponding accounts of the negotiable instruments, and the corresponding customer information of the accounts. Then, the manager 138 of the payer FI 108 may receive and review this EI 136.

[0019] In some special cases, manager 138 notices that NSF has occurred due to negotiable instrument 100, payee 102 is listed on EI 136, and manager 138 subjectively believes that payee 102 is an important or preferred customer of payee FI 108. In some cases, manager 138 may have the authority to have payee FI 108 pay the negotiable instrument 100, and since the negotiable instrument is then marked as "paid", if the balance is still insufficient and payee FI 112 has not received the NSF item in the returned item file, an NSF notification 139 is sent to payee 102.

[0020] In another example, the manager 138 or other representative of the payee FI 108 may notify the payee 102 that a payment needs to be made on a negotiable instrument 100 on the EI. To make the payment on the instrument 100, the payee must personally pay the manager or his designee, who must then locate the NSF record in the payee FI 108 system and manually mark the negotiable instrument 100 as "paid."

[0021] However, if Payee 102 does not deposit the funds within the time specified by Payee FI 108, Payee FI 108 will send the item to Payee FI 112 as a returned check file marked as NSF.

[0022] As mentioned above, this process is completely time-sensitive, but requires manual work. If the payee does not pay the required amount within the FI scheduled period, the payee will still be classified as having an NSF, and the relevant negotiable instrument that caused the NSF will not be honored and will be returned due to insufficient funds. In addition, even if the payee starts paying the required amount within the FI scheduled period, the payment may not be settled until after the FI scheduled period expires, with the same result. Summary of the invention

[0023] One aspect of the present invention relates to an improved technology platform for a financial alert management and real-time remediation system (FAMS). The platform may include some or all of the following technology components and features.

[0024] FAMS includes a set of computer software modules (executing on a processor) that can generate alerts (also referred to herein as notifications) and allow customers to manage and control outcomes based on their decisions and actions in a real-time environment over a specified period of time. FAMS provides a technology solution that leverages real-time communications to empower customers (both individuals and businesses) to take actions to minimize costs that would otherwise be incurred and to protect their credit status, reputation, and identity. In addition, it provides a protective and secure way to exchange information, remedy situations, and provide options in a real-time environment to benefit customers.

[0025] FI electronically generates exception information (EI) describing one or more events (such as NSF or other events) and automatically transmits EI to the platform. The system can be configured so that EI has a specific data structure. A component of the data structure may include information about specific rules applicable to specific events in EI. These rules can be based on a set of information related to a specific event and a set of rules in a rule database. Therefore, the rules for one event may be different from the rules for another event. The platform parses EI into events, processes events in EI according to the rules, and generates customized electronic notifications to send to customers, with links. The link enables customers to access the platform, for example, using a browser running on a customer device after authentication through a single sign-on (SSO) feature associated with a customer account at FI. After authentication, the SSO interface of FI can redirect the customer browser to the platform. The Platform generates a user interface to display the Event, the time frame for responding, the action options (e.g., pay, report fraud, return unpaid negotiable instruments), any fees associated with the action (based on rules associated with each Event, which may vary by User), and if a payment action is selected, one or more payment options, including payment options enabled directly from the Platform without requiring the User to use a separate website or application.

[0026] After the customer views the exception notification, they can select an action through a user interface that presents a set of options, including the option to make a payment to resolve the incident. If the customer selects the payment action, the platform will facilitate the real-time communication of the customer selection and any payment information received from the customer to the FI to enable instant and automatic posting of the payment directly to the customer account without further manual interaction.

[0027] FAMS reduces the occurrence of chargeback events in which a payee FI refuses to pay a negotiable instrument issued by a payee having a payee account at the payee FI, which results in a non-sufficient funds (NSF) event because the monetary amount of the negotiable instrument exceeds the amount of funds available in the payee account.

[0028] FAMS may include a communication module, a database, a timing module, a second communication module, a decision module, a payment module, and a settlement module. The controller may communicate signals with the first communication module, the second communication module, the payment module, the timing module, and the database. The controller is configured to control the operation of the system. The first communication module is configured to receive EI, payer contact data, and FI scheduled deadlines from the payer FI. The EI generated by the payer FI includes all events submitted and processed through night processing that result in insufficient final fund balances.

[0029] The payee contact data includes the payee's contact information, and the FI predetermined deadline for receiving funds to make up for the NSF event before the non-payment event of the payee FI's rejection of the negotiable instrument occurs. The database is configured to store the NSF event from the EI and utilize the payee's contact information from the payee contact data. The timing module is configured to generate the FAMS deadline based on the FI predetermined deadline. The second communication module is configured to attempt to communicate with the payee based on the payee's contact information, and if successful, transmit the NSF event to the payee, the option to take action to change the order of events by selecting "pay", "return" or "fraud", and / or pay the amount required to resolve the NSF event. The payment module is configured to receive payment from the payee.

[0030] As an example of operation, a system performs a method to reduce the occurrence of chargeback events in which a payer FI refuses to pay a payer-generated negotiable instrument that results in a NSF event because the monetary amount of the negotiable instrument exceeds the amount of available funds in the payer's account. The method may include: (electronically) receiving EI (e.g., as a data structure), the EI including, for example, payer contact data, FI reservation deadlines, rules, and / or other data from the payer FI; parsing the data structure to extract various components; storing data items (including NSF events from the EI), and storing payer contact information from the payer contact data.

[0031] The method may also include generating a FAMS deadline based on the FI predetermined deadline and attempting to communicate with the payer based on the payer's contact information. If the attempted communication is successful, the method may include transmitting the NSF event, the option to take action, the amount required to cover the NSF event, and the FAMS deadline to the payer in real time. The method may include receiving a payment from the payer. BRIEF DESCRIPTION OF THE DRAWINGS

[0032] The invention, in accordance with one or more various embodiments, is described in detail with reference to the following drawings. The drawings are provided for illustration purposes only and merely depict typical or example embodiments.

[0033] Figure 1 is a block diagram of an example of an implementation of a known method of making a payment between two persons using a negotiable instrument.

[0034] Figure 2 is a block diagram of a financial system according to some implementations of the disclosed technology.

[0035] Figure 3is a flow chart according to some embodiments of the disclosed technology, illustrating a process by which a customer and a financial institution manage overdrafts or accommodation payment items (collectively referred to herein as "overdraft events") in a customer's account.

[0036] Figure 4 Depicted are example user interfaces that may be provided to customers in accordance with some implementations of the disclosed technology.

[0037] Figure 5 is a flow chart illustrating a process of determining overdraft fee pricing from a pricing model grid in accordance with some embodiments of the disclosed technology.

[0038] Figure 6 An example first user interface that may be provided to a customer for easy selection of a treatment approach according to some implementations of the disclosed technology is depicted.

[0039] Figure 7 An example second user interface that may be provided to a customer for easy selection of a treatment approach in accordance with some implementations of the disclosed technology is depicted.

[0040] Figure 8 Depicted are example user interfaces that may be provided to customers for making AI decisions based on prior activity in accordance with some implementations of the disclosed technology.

[0041] Fig. 9 Depicted is an example user interface that may be provided to a customer for analyzing "how much can I afford" in accordance with some implementations of the disclosed technology.

[0042] Fig.10 Depicted is an example user interface that may be provided to a customer via a savings estimation tool in accordance with some implementations of the disclosed technology.

[0043] Fig.11 Depicted is an example user interface that may be provided to a customer for analyzing "how much I saved" in accordance with some implementations of the disclosed technology.

[0044] Fig.12 is a flow chart illustrating a process for a real-time cashier's check anti-fraud tool in accordance with some implementations of the disclosed technology.

[0045] Fig.13 is a flow chart illustrating a process for a real-time fraud item reporting tool according to some implementations of the disclosed technology.

[0046] Fig.14 Depicted is an example user interface that may be provided to a client by a real-time fraud item reporting tool in accordance with some implementations of the disclosed technology.

[0047] Fig.15 is a flow chart illustrating a debit card automatic opt-in process according to some embodiments of the disclosed technology.

[0048] Fig.16 is a flow chart illustrating a process for providing automated clearing house (ACH) warehouse analytics in accordance with some implementations of the disclosed technology.

[0049] Fig.17 Depicted is an example user interface that a client may use to request an ACH warehouse analysis in accordance with some implementations of the disclosed technology.

[0050] Fig.18 Depicted is an example user interface that may be provided to a client by a real-time fraud item reporting tool in accordance with some implementations of the disclosed technology.

[0051] Fig.19 is a flow chart illustrating a process for automated general ledger (GL) reconciliation according to some implementations of the disclosed technology.

[0052] Fig. 20 are example computing components that may be used to implement various features of the embodiments described in this disclosure.

[0053] The drawings are not intended to be exhaustive or to limit the invention to the precise form disclosed. DETAILED DESCRIPTION

[0054] Embodiments of the disclosed technology include a financial alert management system (FAMS) with real-time remediation capabilities, which can interact with one or more financial institutions (FIs), one or more customer electronic devices, and one or more external payment provider systems. In the described embodiments, FAMS is a system separated from the payee FI. For example, FAMS may include a server that is programmed with computer instructions to be operated to provide services as described herein to various FIs. In other embodiments, some or all of the elements of FAMS may be provided and / or operated by the payee FI as part of its internal system. The payee FI may be a bank, a savings and loan institution, a credit union, a trust company, a mortgage company, or a similar FI. An external payment provider may be, for example, a credit card company, an online payment company, or a similar FI.

[0055] FAMS may include a server programmed with a set of software modules that allow a client to manage and control outcomes based on the client's decisions and actions in a real-time environment over a specified period. FAMS also includes intelligent data analysis capabilities that derive scores from historical data based on current data from a variety of input sources. FAMS enables clients (both individuals and businesses) to take actions to minimize costs that would otherwise be incurred and to protect their credit status, reputation, and identity information. In addition, FAMS provides a protective and secure way to exchange information, remedy situations, and provide options in a real-time environment to benefit clients.

[0056] Figure 2 is a block diagram of a financial system 200 according to some embodiments of the disclosed technology. Figure 2 , the financial system 200 may include a financial alert management system (FAMS) 204 with real-time remediation capabilities, which can communicate with one or more payer financial institution systems 202, one or more customer devices 208, and one or more external payment provider systems 210 (e.g., via a network 212) and interact.

[0057] FAMS 204 can be implemented as one or more networked computer systems, such as described in detail below. In the described embodiment, FAMS 204 is a system independent of payer financial institution system 202. For example, FAMS 204 can be operated to provide services for financial institutions. In other embodiments, some or all of the elements of FAMS 204 can be provided and / or operated by payer financial institution 202 as part of its internal system.

[0058] The payee financial institution may be a bank, savings and loan institution, credit union, trust company, mortgage company, or similar financial institution. The external payment provider 210 may be, for example, a credit card company, an online payment company, or a similar financial institution.

[0059] The client device 208 may be operated by a client 206 who has a financial account at a payer financial institution. The client device 208 may include, for example, a smartphone, a tablet computer, a personal computer, and similar electronic devices. One or more networks 212 (e.g., a wired or wireless network, the Internet, or other networks) may interconnect the elements of the financial system 200 and enable communications between them.

[0060] Overdraft and Concession Payment Processing

[0061] The related U.S. Patent No. US11,144,917B1 provides a financial alert management and real-time remediation system (FAMS) that allows customers to remedy the above-mentioned insufficient funds (NSF) events in real time. However, financial institutions also generate other items that are not included in the exception processing because they have been paid (referred to as "other submitted items" herein). For example, the items submitted every day include paid items, NSF items and transactions caused by insufficient funds, and paid items and transactions if the financial institution provides an overdraft or accommodative payment service (Courtesy Pay service). The embodiment of the disclosed technology provides an improved financial alert management and real-time remediation system (hereinafter referred to as "FAMS"), which creates a panoramic view of all submitted items (whether paid or not) for customers, and allows customers to fully control the items they want to pay and the items they want to return (if any). As described above, these items are different from conventional NSF exceptions (returned due to insufficient balance) and are not included in the exception processing because they have been paid, so these "other submitted items" will not be listed separately in the exception task for review. Therefore, Core Processor has not yet provided reports on these “other submissions” to any external partners.

[0062] One shortcoming of the current system is that items that have been paid but are overdrawn are not reported in any separate report or task to be easily displayed to the customer. In addition, these items are considered paid, so if the customer requests a refund for these items, there is no pre-established automated system to refund these items. Therefore, making changes to paid items is currently a manual, time-consuming and risky process. The risk arises when a customer wishes to refund an item but the refund deadline for that item has passed. Such items are considered "late refunds" and may be rejected as unacceptable late refunds, and the bank will be liable for the item.

[0063] Figure 3 300 is a flow chart of some embodiments of the disclosed technology, illustrating a process 300 for a customer to manage an overdraft or accommodation payment item (collectively referred to herein as an "overdraft event") in a customer's account with a financial institution. For example, when a check drawn on a customer's checking account exceeds the available balance of the account at the time of submission but does not exceed the overdraft amount of the financial account, the process 300 can be used for a customer to manage an NSF event in his or her checking account. The process 300 refers to Figure 2 and Figure 3 Describe and can be Figure 2 FAMS 204 is implemented in

[0064] The elements of the disclosed process are presented in an arrangement. However, it should be understood that one or more elements of the process can be performed in a different order, in parallel, or omitted entirely. In addition, the process can include other elements in addition to the elements presented. For example, if an exception occurs, the process can include error handling functions.

[0065] refer to Figure 3 , process 300 may include obtaining an electronic file at 302. The electronic file may include an overdraft information data structure including overdraft information representing one or more overdraft events and customers associated with the overdraft events. The file may include a contact information data structure including an electronic address for each customer. The file may include rules specific to each instance / customer that are different from rules for other instances / customers.

[0066] The file may include information describing the event and customer information about the customer. The information may include the date and time the event was generated, a unique identification code (UIC) used to uniquely identify each event, the account number of the customer account involved, the instrument number (e.g., check number) of the negotiable financial instrument (s) involved, the monetary amount of each negotiable financial instrument involved, and other information.

[0067] Customer information may include customer name, customer number, customer contact information, and other information. Customer contact information may include email address, phone number, and other contact information.

[0068] FAMS204 can obtain electronic files electronically from payer financial institution 202 in various ways. In some embodiments, FAMS204 can poll payer financial institution 202 to obtain electronic files. In other embodiments, payer financial institution 202 can push electronic files to FAMS204. In some embodiments, payer financial institution 202 can provide FAMS204 with access programs or application programming interfaces (APIs) to obtain electronic files. In some embodiments, FAMS204 can obtain electronic files by using robotic process automation that simulates the keystrokes of employees of payer financial institution 202. In some embodiments, a combination of these technologies can be used. In some embodiments, FAMS can request a specific program that allows access to the core system to obtain electronic files. These technologies can be executed in a highly encrypted security protocol environment.

[0069] This technical integration between the FAMS and the payer's financial institution to obtain electronic documents is non-traditional and employs novel technical collaboration between the FAMS computer system and the computer system of the payer's financial institution. Traditionally, the process of receiving electronic documents from the FI is accomplished in whole or in part manually. These manual processes consume valuable time in a time-critical process. The described automated electronic collaboration between the payer's FI and FAMS occurs almost instantaneously, providing the payer with more time to process the event.

[0070] Reference again Figure 3 , process 300 may include: in response to obtaining the overdraft information, automatically parsing the overdraft information into an overdraft event for a customer associated with the overdraft event at 304. After completing the parsing, process 300 may include one or more subsequent operations for one or more customers.

[0071] For example, process 300 may include generating and sending an overdraft notification message to the customer's electronic address at 306. The overdraft notification message may include a link to an authentication interface of an institution associated with the customer.

[0072] For example, refer again to Figure 2 After obtaining the overdraft information, FAMS 204 may identify customer 206 based on the customer information in the overdraft information, and may provide some or all of the overdraft information to the customer device based on the contact information in the customer information. For example, the notification may include information about a time interval during which the customer can resolve the overdraft event, such as the end time of the interval and the time remaining in the interval. The notification message may include an email, a text message, a voicemail, an automated voice call, and the like.

[0073] The link may be a hyperlink to a single sign-on (SSO) authentication interface of the payer financial institution 202. The customer 206 may enter the link in a browser executed on the customer device 208 to access the SSO interface, and may authenticate by logging into the SSO interface, for example, by providing a preset user ID and password. In some embodiments, the authentication process may include multi-factor authentication.

[0074] Reference again Figure 3 , process 300 may include, at 308, providing a user interface to the electronic customer device for display to the customer in response to the customer authenticating through the authentication interface of the financial institution. The user interface may display overdraft information for each overdraft event associated with the customer, and display elements from which the user may select, including display elements for payment options. For example, again referring to Figure 2 , FAMS 204 may provide a user interface to client device 208 .

[0075] Figure 4 An example user interface 400 that may be provided to a customer according to some implementations of the disclosed technology is depicted. Figure 4 , at 402, the user interface 400 may list the negotiable financial instrument(s) involved, and for each instrument, information such as the check number and amount may be listed. The user interface may also list one or more service fees charged by the financial institution to process the exception. The customer may select the fee(s) to pay using the user interface. The user interface may list the total amount due. The customer may simply select the total amount due.

[0076] User interface 400 can list the decision of the financial institution for each bill at 408. The FI decision represents the decision made by the FI regarding the disposal of the bill. For example, the financial institution can decide that the bill should be paid, paid by an accommodating payment, or should be returned. At 410, interface 400 also allows the customer to overrule these decisions. For example, the customer can decide to pay the bill, return the bill to the payee, report bill fraud, or stop paying the bill. In response to such a customer selection, the FAMS can send an electronic message representing the decision to the FI.

[0077] Reference again Figure 3 , process 300 may include generating and sending a payment message in response to the customer selecting a payment option at 310. The payment message may cause a transfer to an institution, such as to a financial account of the customer. The payment amount may be greater than or equal to the difference between the monetary amount of the transferable financial instrument(s) and the monetary balance of the financial account. For example, the payment amount may be the sum of the service fee(s) and the difference between the monetary amount of the transferable financial instrument and the monetary balance of the financial account.

[0078] In some embodiments, the user interface may list more than one payment method in the user interface. For example, the payment method may identify an account that the customer has with an external payment provider 210. In such embodiments, in response to the customer selecting one or more payment methods, FAMS 204 (or a third party) may transfer the payment amount to the customer's financial account according to the selected payment method(s).

[0079] In some embodiments, the user interface may provide other action options besides insufficient funds (NSF) for payment. For example, the user interface may provide the customer with an option to report fraud related to the negotiable financial instrument(s) involved. In such embodiments, in response to the customer selecting the option to report fraud, the FAMS 204 may report the fraud related to the negotiable financial instrument to the payee financial institution 202.

[0080] In some implementations, in response to the expiration of a time interval to resolve an NSF event, the FAMS system may provide an indication of the expiration of the time interval in the user interface and may disable or delete the payment option in the user interface.

[0081] Pricing overdrafts from the pricing model grid

[0082] FIs often charge customers a fee for a declined transaction. For example, a FI might charge a customer an overdraft fee for an overdrawn note. The note could be a debit card, check, ACH note, or similar note. The fee is usually fixed and independent of the amount of the note. For example, the fee could be set at $30. To many people, this fee seems excessive when the amount of the note is similar to or less than the fee. However, in the current system, the fee is fixed regardless of the amount of the note.

[0083] In some embodiments, fees may vary based on the amount of the associated transaction. For example, fees may be defined in a pricing grid. An example pricing grid is provided below, as shown in Table 1. Referring to Table 1, the pricing grid establishes multiple intervals for transaction amounts, up to a predetermined debit limit. For each interval, the pricing grid sets an associated fee amount. For example, for transaction amounts less than $25.00, the pricing grid of Table 1 sets a fee of $5.00. For the highest interval, the fee amount may be a default service fee. In some embodiments, the pricing grid may assign a different fee code to each interval and fee amount. Referring again to Table 1, for the above example, the fee code is 01.

[0084] Trading Range ($) Fee Amount ($) Fee Code 0-25.00 5.00 01 25.01-75.00 10.00 02 75.01-150.00 15.00 03 150.01-250.00 20.00 04 250.01-1,000.00 25.00 05 1,000.01 - Debit limit Default service fee amount 06

[0085] Figure 5 5 is a flow chart illustrating a process 500 for pricing overdraft fees from a pricing model grid according to some embodiments of the disclosed technology. For example, process 500 may be used by a customer to manage NSF events in a customer's checking account when a check drawn on the customer's checking account exceeds the available balance of the account at the time of presentation but does not exceed the overdraft limit amount of the financial account. Process 500 references Figure 2 and Figure 5 is described and can be represented by Figure 2 Implementation of FAMS204.

[0086] refer to Figure 5 , process 500 may include obtaining an electronic file in 502. The electronic file and the method of obtaining the electronic file may be as described above with reference to Figure 3 described.

[0087] Reference again Figure 5, process 500 may include: in response to obtaining the overdraft information, automatically parsing the overdraft information into an overdraft event for a customer associated with the overdraft event at 504. After the parsing, process 500 may include one or more subsequent operations for one or more customers.

[0088] For example, process 500 may include, at 506, determining a service fee based on the amount of the associated transaction. In some embodiments, the pricing grid may be stored in the FAMS. In these embodiments, the FAMS may index the grid with the transaction amount to determine the fee. The FAMS may also determine the fee code in a similar manner. The FAMS may provide the fee code to the FI or core processor.

[0089] In other embodiments, the fee amount may not be stored in the FAMS, but may be stored in the FI. In these embodiments, the FAMS may determine a fee code based on the transaction amount, and may provide the fee code to the FI. In response to receiving the fee code, the FI may determine the fee amount based on the fee code, and may refund the fee amount to the FAMS.

[0090] Process 500 may include: at 508, generating an overdraft notification message and sending it to the customer's electronic address. The overdraft notification message and the method of sending the overdraft notification message may be as described above. Figure 3 The overdraft notification message may include a link to an authentication interface of an institution associated with the customer. The link and authentication process may be as described above with reference to Figure 3 described.

[0091] Reference again Figure 5 , process 500 may include: at 510, in response to the customer being authenticated by the authentication interface of the financial institution, providing a user interface to the customer electronic device for display to the customer. The user interface may display overdraft information for each overdraft event associated with the customer, and display elements from which the user may select, including display elements for payment options. For example, again referring to Figure 2 , FAMS 204 can provide a user interface to client device 208. The user interface can be similar to the Figure 4 User interface.

[0092] Reference again Figure 5 , process 500 may include: at 512, in response to the customer selecting a payment option, generating and sending a payment message. The processing of the payment message may be as described above with reference to Figure 3 described.

[0093] Easily choose the disposal method

[0094] The disclosed FAMS presents a variety of deals and options to customers. Many customers and small businesses do not have the time to analyze these deals and options in detail, but still want the opportunity to choose the right option for each deal. Complicating factors include small equipment and other time constraints.

[0095] In some embodiments, FAMS provides an easy selection of dispositions for these items by providing a "Quick Select" button as a display element in the user interface. Instead of making a separate decision for each transaction, the customer can select a decision type and select all transactions that apply to the selected decision type. This process is particularly effective when the number of transactions is large. Through this technology, individuals or small business operators can make their decisions in seconds instead of minutes. In some embodiments, FAMS then automatically groups transactions by decision type to quickly verify the decisions made.

[0096] Figure 6 An example first user interface 600 that may be provided to a customer for easily selecting a treatment method according to some embodiments of the disclosed technology is depicted. The user interface 600 may be provided as described above, which may follow the authentication and notification methods described above. Figure 6 , at 602, a user interface 600 may list items. The list may include an account number, a description such as the name of the payee, and the amount of the item. The user interface 600 may include a user-operable member decision drop-down menu display element 604 for each item in the list. The user may operate the display element 604 as described above to make decisions for each item in the list. At 606, the user interface 600 may also include a user-operable quick decision display element. The customer may operate the display element 606 to select a decision type to be applied to multiple items in the list, for example, to speed up the decision process.

[0097] Figure 7 An example second user interface 700 that may be provided to a customer for conveniently selecting a treatment method according to some embodiments of the disclosed technology is depicted. Figure 7 , the customer has operated the convenient decision display element 606 to select the decision type "I want to pay". Other possible decision types may include decisions to pay the bill, return the bill to the payee, report bill fraud, or stop paying the bill. After selecting a decision type, the customer can apply the decision type to certain items by selecting them. Figure 7 , in 702, the selected item is marked with a "P". In response to the customer selection, the FAMS may send an electronic message to the FI indicating the decision, such as described above.

[0098] Artificial intelligence (AI) decisions based on previous activity

[0099] Financial institutions have always followed a certain transaction submission hierarchy to process debit and credit card transactions. This process is fixed and includes assumptions about which transactions a customer (such as a consumer or small business) wants to pay for.

[0100] Until now, financial institutions have had no way to know or intelligently guess which transactions customers want to pay for, and can only default to a fixed, established tier system. This approach can cause customer dissatisfaction and problems, as items that are critical to customers may be rejected.

[0101] In some embodiments, the FAMS may use the customer's previous activity to select a default decision for the customer's current transaction. For example, the FAMS may keep a record of the decisions that the customer has selected in the past for a particular transaction. The FAMS may also keep a record of the payment method that the customer used when selecting a payment decision.

[0102] In some embodiments, FAMS uses algorithms to build a database of predictable actions to present to customers. The financial institution's transaction submission hierarchy becomes outdated and the default decisions selected now reflect the customer's past behavior. This process produces faster and more accurate decisions.

[0103] In some embodiments, the process may employ artificial intelligence. For example, the process may employ one or more machine learning models. Any machine learning model and technique may be used. For example, machine learning models and techniques may include decision trees, neural networks, gradient boosting algorithms, and similar machine learning models and techniques. The machine learning model may be pre-trained with a historical correspondence between the decision made and the parameters of the corresponding transaction. The training may be supervised, unsupervised, or a combination thereof, and may be continued throughout the operation of the system. Over time, the training may continue using the model to improve its accuracy. The parameters may include, for example, but not limited to, an account number, the identity of the payee, the amount of the item, the date of the item, the payment type (e.g., check, ACH, or debit card), and the final decision to process the item. A time frame and weight may be assigned and calculated for each data point to determine a mode of action.

[0104] When a new project is submitted, the parameters of the new project can be applied as input to the trained model. In response, the model can provide a default decision. FAMS can present the project, the default decision, and one or more parameters to the user in the user interface. This process can follow the above-mentioned authentication and notification procedures.

[0105] Figure 8An example user interface 800 that may be provided to a customer for making AI decisions based on previous activity according to some implementations of the disclosed technology is depicted. The user interface 800 may be provided as described above, which may follow the authentication and notification methods described above. Figure 8 , in 802, a user interface 800 may list items. The list may include an account number, a description such as the name of the payee, and the amount of the item. The user interface 800 may include display elements 804 that list the automatic decisions for one or more items. Each display element 804 may include a drop-down menu that allows the customer to change the decision. In response to the customer selection or confirmation of the automatic selection, the FAMS may send an electronic message to the FI indicating the decision, such as described above.

[0106] "How much can I afford" analysis

[0107] When there are multiple items to pay for, it can be difficult for a client who does not have enough funds to pay for all of them to determine how much they can afford, which items to pay for, and how to pay for them. Budget models can sometimes help clients, but they do not provide timely and specific answers to these questions. Returning items can increase overall costs by incurring additional fees and can have a serious negative impact on a client's credit rating, reputation, and future payment terms.

[0108] In some embodiments, FAMS can provide a calculator tool to provide timely and specific answers. For example, the tool can provide the customer with some options for how much money the customer can pay to remedy some or all of the items submitted. This calculation varies depending on what the financial institution provides and what they want to include in the calculator. The tool is not a budget calculator. Instead, the tool is a calculator that helps the customer find and use funds from multiple sources that the customer may already have or be able to obtain. The tool can provide a combination of questions and blank answer boxes for the customer to fill in to calculate the amount the customer can pay.

[0109] Fig. 9 An example user interface 900 that may be provided to a customer for a "how much can I afford" analysis according to some implementations of the disclosed technology is depicted. The user interface 900 may be provided as described above, which may follow the authentication and notification methods described above. The user interface 900 may be presented in response to a user selecting a user-operable "how much can I afford?" display element, which may be presented in a user interface that lists items to be paid (e.g., including one or more of the user interfaces described above).

[0110] refer to Fig. 9In 902, user interface 900 can list multiple sources of funds. For example, the source can include cash, credit card, debit card, money transfer from accounts of other financial institutions, online payment systems, micro loan services, and similar sources of funds. The customer may not know the payment resource options or how to use them. The system not only presents these options, but also allows customers to access them within the scope of technology. If the customer does not have cash, other available funds, or available credit on the card, the micro loan application can be embedded in the technology as an additional source of funds. As the customer adds sources of funds, in 904, the dollar amount representing the total amount that the customer can afford based on these sources and the customer's account at the financial institution can be displayed.

[0111] A user-operable "transaction priority" display element 906 allows the customer to change the order of submission selected by the financial institution. By allowing the customer to re-prioritize or re-order transactions, they are able to pay for the transactions they consider most important and return other less important transactions. In some cases, no additional funds are required.

[0112] "How much did I save" analysis

[0113] In a world filled with fees and negative consequences, it's helpful to show customers how much money they saved by taking specific actions. However, these savings can be difficult to calculate, especially when it comes to transactions submitted that resulted in an overdraft on an account. Additionally, the estimated savings per transaction can vary depending on the type and timing of the transaction. When it comes to non-sufficient funds and overdraft (NSF / OD) items, the technology used for such estimates is particularly difficult or even non-existent.

[0114] In some embodiments, FAMS provides a savings estimator tool to estimate how much a customer saves. Fig.10 An example user interface 1000 that may be provided to a customer via a savings estimation tool according to some implementations of the disclosed technology is depicted. The user interface 1000 may be provided as described above, which may follow the authentication and notification methods described above. Fig.10 , the user interface 1000 may list the submitted items, and for each item, the customer may be prompted to answer certain questions. The savings estimator tool also has a novel processing backend that estimates the savings based on the answers provided by the customer.

[0115] In one example, the tool may determine a payee for each item, such as by processing an image of the item. Based on the payee, the tool may then ask what the item is for (e.g., rent payment, mortgage payment, credit card payment, or auto loan payment). Based on the purpose, the tool may estimate a savings amount. The estimated savings amount may include priority returned item fees, late payment fees, restocking fees, insurance reactivation fees, collection fees, telephone reactivation fees, and the like.

[0116] Many retail receipts list a sales discount based on the original price. When these transactions are submitted as non-sufficient funds / overdrawn (NSF / OD) items, the savings can be difficult to determine. Currently, these savings are estimated based on industry standards and the most likely cost. The savings estimator tool asks customers questions to make this determination.

[0117] Likewise, the tool can factor in late fees or restocking fees for returned merchandise. Currently, these fees are estimated as a percentage of payment. The savings estimator asks customers questions to make this determination.

[0118] When estimating savings, the tool may take into account the type of transaction. For example, for a returned item, the tool may assume an industry standard returned item fee, such as $25.00.

[0119] Fig.11 An example user interface 1100 that may be provided to a customer for a "how much did I save" analysis according to some implementations of the disclosed technology is depicted. The user interface 1100 may be provided as described above, which may follow the authentication and notification methods described above. The user interface 1100 may be presented in response to a user selecting a user-operable "how much did I save?" display element, which may be presented in a user interface that lists items to be paid (e.g., including one or more of the user interfaces described above). Reference Fig.11 , the user interface 1100 can be based on the user Fig.10 The decision selected on the user interface 1000 provides an overall summary review of the estimated savings.

[0120] Real-time Cashier's Check Fraud Prevention Tool

[0121] Cashier's checks are prepaid bank checks that customers buy and use, usually for large transactions such as loan settlements or the purchase of large dollar items. Banks and merchants trust that cashier's checks will be paid because they are prepaid by the customer. However, cashier's checks are sometimes fraudulent. There is currently no way to determine if a cashier's check is fraudulent. Banks and merchants typically accept cashier's checks in good faith, hoping that they are not fraudulent. But there is currently no technological solution to "confirm" or "guarantee" that a cashier's check is valid before it is cashed.

[0122] In some embodiments, FAMS can provide a real-time cashier's check fraud prevention tool that uses financial institution data to verify the authenticity of a cashier's check before it is accepted. Users of this technology have the unique advantage that when a cashier's check is scanned or entered into FAMS, the central hub verifies certain criteria. The parameters that FAMS uses to verify a cashier's check can include the date, routing number, account number, check number, amount, and payee. Through a secure data line, FAMS can verify check data by connecting to various systems, including core systems, forward payment systems, accounting systems, and other systems that store cashier's check data.

[0123] Fig.12 is a flow chart illustrating a process 1200 for a real-time cashier's check fraud prevention tool according to some embodiments of the disclosed technology. The process 1200 refers to Figure 2 and Fig.12 is described and can be represented by Figure 2 Implementation of FAMS204.

[0124] refer to Fig.12 , process 1200 may include obtaining an electronic file at 1202. The electronic file may include a cashier's check data structure that includes cashier's check information for one or more cashier's checks presented at a first institution. For example, a tool may provide a user interface for an electronic device of an institution. The user interface may include a display element that allows a user of the institution to enter cashier's check information for one or more cashier's checks presented at the first institution. In some embodiments, the user may manually enter the information, and the file includes the entered information. In some embodiments, the user may simply scan a check, and the file may include an image of the check. The electronic file and the method of obtaining the electronic file may be as described above with reference to Figure 3 described.

[0125] Reference again Fig.12 , process 1200 may include: in response to obtaining the cashier's check information, automatically parsing the cashier's check information into one or more cashier's check events based on the remittance routing number in the cashier's check information at 1204. After completing the parsing, process 1200 may include one or more subsequent operations for one or more customers.

[0126] The process may include identifying the second institution based on the remittance routing number. For example, the second institution may be a drawer or payee of a cashier's check, a core processor, or the like. The process may include determining whether the second institution supports the fraud prevention tool. If not, the tool may send a message to the first institution indicating that the second institution is not a participating financial institution.

[0127] However, if the second institution supports fraud prevention tools, process 1200 may include sending an electronic verification request message to the second institution at 1206. The electronic verification request message may include one or more of an account number, an amount, a date, a check number, and a payee of a corresponding cashier's check. Messages may be exchanged with the institution by accessing an application programming interface (API) of the institution.

[0128] Process 1200 may include, at 1208, receiving an electronic verification reply message in response to the electronic verification request message. Process 1200 may include, at 1210, determining whether the cashier's check has been verified based on the electronic verification reply message.

[0129] Process 1200 may include sending an electronic reply message to the institution at 1212, wherein the electronic reply message indicates whether the cashier's check has been verified. For example, the tool may provide a user interface for an electronic device of the institution. The user interface may include a display element that indicates whether the cashier's check has been verified based on the electronic reply message.

[0130] Real-time fraud reporting tool

[0131] Occasionally, fraudulent items appear on customer accounts awaiting payment. A common example is a fraudulent check. Currently, there is no way for customers to detect and report fraudulent items in real time or even in a timely manner for a number of reasons. Some processing methods do not credit the item to the customer account until after the 24-hour window for returning the item has closed. Therefore, by the time the customer sees the item, it is already too late to return it within the 24-hour window. Even if the processing system credits the customer account within the 24-hour window, it typically does not provide notification to the customer to allow timely review of the item(s). And even if the customer has configured such notifications, the customer must still review the items within the 24-hour return window, determine if they are fraudulent, manually notify the financial institution, complete the required paperwork, and manually return the items.

[0132] As a result, it may be days before the customer learns of the fraudulent item. The customer must then deal with negative consequences because the unexpected item was paid for with the customer's available balance. In addition, paying for the item may cause other items to be returned, for example due to insufficient funds in the customer's account. Such item returns may damage the customer's relationship with the merchant and may result in the customer being charged additional fees by a third party (e.g., returned check fees, late fees, restocking fees), and poor payment terms in the future.

[0133] Financial institutions may also suffer adverse consequences. These institutions may need to compensate customers and pay for other fraudulent items because the institution learns about the fraudulent items too late. For example, a customer's financial institution that accepted a fraudulent item for deposit (i.e., the payee financial institution) may not know that the item is being returned. This results in a loss on the part of the payee financial institution. If an item is deemed fraudulent and is returned, the payee bank must return the item to the customer who made the deposit. If the customer does not have enough balance to cover the returned item, they will be overdrafted until they can repay the fraudulent funds they have used.

[0134] In some embodiments, FAMS provides a real-time fraudulent item reporting tool that allows customers to indicate that a submitted item will create an overdraft, is a fraudulent item, and can be returned within a 24-hour return window. The tool not only notifies the customer of the specific item that caused the overdraft situation, but also provides an option to "report fraud" directly in the user experience. Other than logging a customer report of fraudulent or unauthorized activity, the item is immediately marked as returned and the financial institution does not need to take any action. This tool allows customers to prevent problems before they occur. And the payer's financial institution can avoid fraud losses caused by delayed returns.

[0135] Additionally, if the payee's bank supports the tool, FAMS immediately notifies the payee's financial institution that the item is being returned. Typically, this notification process takes at least 24 hours and only occurs if the item is over a certain dollar amount. Currently, smaller items do not require 24-hour notification. FAMS's notification allows the payee's financial institution to act quickly to reserve funds in the payee's account to refund when the chargeback arrives, thereby mitigating additional losses.

[0136] Fig.13 is a flow chart illustrating a process 1300 for a real-time fraud item reporting tool according to some embodiments of the disclosed technology. The process 1300 refers to Figure 2 and Fig.13 is described and can be represented by Figure 2 Implementation of FAMS204.

[0137] refer to Fig.13 , process 1300 may include obtaining an electronic file from a first institution at 1302. The electronic file may include an exception information data structure and a contact information data structure, the exception information data structure including exception information representing one or more events, customers associated with the events, and negotiable financial instruments associated with the events and issued on customer accounts of a payer financial institution, and the contact information data structure including an electronic address of each customer. The electronic file and the method of obtaining the electronic file may be as described above with reference to Figure 3 described.

[0138] Process 1300 may include, in response to obtaining the exception information, automatically parsing the exception information into an event of a customer associated with the event by a computer processor at 1304. After the parsing, process 1300 may include one or more subsequent operations for one or more customers.

[0139] Process 1300 may include, at 1306 , generating, by the computer processor, and sending, to the customer's electronic address, an event notification message, wherein the event notification message includes a link to an authentication interface of the payer's financial institution.

[0140] Process 1300 may include, in response to the customer being authenticated by the authentication interface, providing, by the computer processor, a user interface to the electronic customer device for display to the customer at 1308. The user interface may display information about each event associated with the customer and display elements from which the user may select, including a display element for reporting fraud associated with the corresponding negotiable financial instrument.

[0141] Process 1300 may include, in response to a customer selecting a display element for reporting fraud, generating and sending a first fraud reporting message to a payer financial institution and generating and sending a second fraud reporting message to a payee financial institution at 1310. The first fraud reporting message and the second fraud reporting message may identify corresponding negotiable financial instruments.

[0142] Fig.14 An example user interface 1400 that may be provided to a customer by a real-time fraud item reporting tool according to some implementations of the disclosed technology is depicted. The user interface 1400 may be provided as described above, which may follow the authentication and notification methods described above. Fig.14 , user interface 1400 can list items at 1402. The list can include an account number, a description such as the name of the payee, and the amount of the item. User interface 1400 can include display element 1404 that lists the decisions made by the financial institution (FI) for these items. User interface 1400 can include user-operable display elements 1406 that also list the decisions of the financial institution for these items. Each display element 1406 can provide options, such as through a drop-down menu or other user-operable display element that allows the customer to change the decision. Fig.14 In the example of , at 1408, the customer has operated the drop-down menu of the first listed item, indicating that it is fraudulent.

[0143] Real-time debit card automatic opt-in process

[0144] When a customer attempts to pay with a debit card, but the funds in the card account are insufficient to cover the transaction, the transaction is declined. Many debit cards address this shortcoming by allowing customers to "opt in" to a debit card overdraft facility. If the customer opts in, the debit card transaction will be paid for with the overdraft. However, many customers do not opt ​​in due to concerns about overdraft fees. And because debit card transactions are so convenient, customers often do not carry checks or cash as an alternative payment method. Thus, if a debit card transaction is declined, the customer has no other source of payment. This can be a serious problem for a customer who is stranded at a grocery store or gas station without a source of payment, for example. In addition, the debit card authorization process is so fast (on the order of nanoseconds) that there is no time to process the transaction differently or to notify the customer of the option to change the "opt-out" status of the debit card.

[0145] In some embodiments, FAMS provides a real-time debit card automated opt-in process. In these embodiments, FAMS can provide the FI with the option to "turn on" this service. The technology is integrated into the card system and triggers a flag when a debit card transaction is declined. This flag is sent to FAMS, which in response sends a message notifying the customer that the transaction has been declined due to the "opt-out" status of the card. The message can be sent via text message (SMS), email, or similar service. Customers who wish to "opt-in" can reply to the message. The reply is received by FAMS. Once the message is received, FAMS sends the Electronic Funds Transfer Act (Reg E) "Opt-in" field maintenance instructions to the core system. Once the field on the core system is updated, the customer can try the transaction again to get approval.

[0146] Fig.15 1 is a flow chart according to some embodiments of the disclosed technology, illustrating a debit card automatic opt-in process 1500. However, although described in terms of a debit card, the disclosed technology is easily applicable to accounts having similar "opt-in" functionality.

[0147] refer to Fig.15 In 1502, a customer uses a debit card to pay for a point of sale (POS) transaction. If the available balance of the debit card account is sufficient in 1504, the transaction can be posted to the core or memorandum system in 1506 and the transaction is successfully completed. However, if the available balance of the debit card account is insufficient in 1504, it can be determined in 1508 whether the customer has opted in to an overdraft protection service. If the customer has opted in to an overdraft protection service, the transaction can be posted to the core or memorandum system in 1506 and can be successfully completed.

[0148] However, if the customer has not opted in to the overdraft protection service, or has opted out of the service, the transaction may be declined, and the FAMS may retrieve contact information from the core processor, for example based on the debit card account number, in 1510, and may trigger an electronic message to the customer in 1512. In 1514, the message may alert the customer to the declined transaction and the opt-in status of the debit card, and may provide the customer with an option to change the opt-in status. For example, the message may provide a user interface on the customer's smartphone having a display element that allows the customer to change the opt-in status. In 1516, in response to the customer changing the opt-in status, the FAMS may send a Reg E "opt-in" field maintenance message to the core system to update the opt-in status of the debit card account. The customer may then attempt the transaction again.

[0149] Warehouse Analysis for Automated Clearing House (ACH) Payments

[0150] The ACH system utilizes warehouses (referred to herein as "ACH warehouses") to store deposits and debits until the date each entry is due to be posted. Financial institutions use ACH warehouses to store ACH entries but do not provide any information to their customers about the next posting. This service is not part of the financial institution's business processes and, therefore, their customers are unaware of upcoming ACH activity.

[0151] In some embodiments, FAMS provides ACH warehouse analytics. FAMS can connect to the ACH warehouse of a financial institution and detect transactions that are about to be posted within the 24-hour return window. FAMS then provides this critical information to the customer in the user interface so that the customer can take actions within the 24-hour window, including the ability to overdraft and pay items. If the customer has a deposit in the ACH warehouse with a posting date within the 24-hour window, FAMS can display this information to the customer in the user interface to notify the customer of the upcoming deposit. This information is very useful when the customer selects a payment method for the payment item of their choice.

[0152] Fig.16 is a flow chart illustrating a process 1600 for providing ACH warehouse analysis according to some embodiments of the disclosed technology. Fig.16 , in 1602, the customer may request an ACH warehouse analysis using the FAMS user interface. Fig.17 An example user interface 1700 is depicted that a client may use to request ACH warehouse analysis according to some implementations of the disclosed technology. The user interface 1700 may be provided as described above, which may follow the authentication and notification methods described above. Fig.17 , the user interface 1700 may present multiple scenarios for the customer to select. Fig.17In the example, these scenarios include scenarios where the customer has no additional funds, scenarios where the customer can pay for the item, and scenarios where the customer has money elsewhere.

[0153] In response to the request, the FAMS may send a query to the ACH warehouse in 1604. The FAMS may access the ACH warehouse using an API provided by the ACH warehouse. In response to the query, the ACH warehouse may search its database for pending transactions in 1606. If any items are found, the ACH warehouse may provide information describing the items to the FAMS in 1610 in 1608. In response, the FAMS may provide the information to the customer in a user interface in 1612.

[0154] Fig.18 An example user interface 1800 that may be provided to a customer by a real-time fraud item reporting tool according to some implementations of the disclosed technology is depicted. The user interface 1800 may be provided as described above, which may follow the authentication and notification methods described above. Fig.18 , user interface 1800 can list details about future and pending transactions.

[0155] Automatic general ledger ( GL ) Reconciliation

[0156] When transactions occur outside of the core processor, it is difficult to achieve any automation due to the required level of access and the requirement for the correct set of transactions to customer accounts and the general ledger (GL). These challenges increase because financial institutions do not allow other external vendors to post entries to their customer accounts or GL. These processes cannot be provided by external vendors due to restrictions and prohibited access.

[0157] In some embodiments, FAMS provides automatic GL reconciliation services. FAMS technology is integrated with the core processor of the financial institution. FAMS also meets many financial audit and security requirements that financial institutions must comply with. Therefore, FAMS can initiate certain processes within the core processor. These processes include customer transactions, various GL transactions, and updating return codes based on the changes in the customer's operations during the day. These processes may also vary depending on the processing level.

[0158] One of these processes is the customer transaction flow. When a customer selects "Pay with Cash" or "Pay with Available Balance," the funds must be reserved by freezing the customer's account. This ensures that the funds cannot be used for other purposes, such as debit card transactions. When a customer selects "Pay with Credit Card," the merchant-approved amount goes into the merchant settlement account instead of being credited to the customer's account, in order to reserve the funds until the item is paid for.

[0159] Other processes include GL transactions. GL transactions include fees, merchant services, and interchange fees. Certain GL processes are triggered on a per-transaction basis. These GL processes are established by the financial institution, but FAMS creates miscellaneous task postings after the action time expires. These GL entries move funds to the appropriate GL and customer accounts, creating an automated settlement process for the financial institution, so manual transactions do not need to be posted.

[0160] Another process is updating return codes. This process is a critical part of “end of day” processing. Default decisions that occur based on the financial institution level posting process need to be updated based on customer decisions throughout the action. For each item, this process does one of the following, including, for example: removing the item from the “return file” so that it is paid; adding the item to the “return file” so that it is returned; and if the return is not due to NSF, changing the return code to reflect the reason for the return (e.g., stop payment in the case of fraud). Other pre-established return codes may be used.

[0161] Fig.19 is a flow chart illustrating a process 1900 for automatic GL reconciliation according to some implementations of the disclosed technology. Fig.19 The processing is shown from left to right. Once the customer selects to pay, return, or report fraud in 1902, the system will be updated in the FAMS database and queued for posting in 1904 after the "action time" expires. At this time, the transaction will be triggered based on the customer's decision, including all fees charged and transactions authorized by the merchant account. At this time, any account freeze opened to retain funds designated for these transactions will be released and the items will be paid through the account. In addition to this process, the return, paid, fraud, and stop payment codes will be updated on the return file to keep a balance with the processed transactions. The established GL is affected by the corresponding transaction amount, including service fees, convenience fees, and merchant settlement amounts (for card transactions). In 1906, the FI's return file is updated based on the changes made by the customer (including deleting paid items, fraud items, and stop payment). All other items in the return file remain as they are.

[0162] Automated FAMS Administration (AFA)

[0163] In some embodiments, FAMS provides a FAMS Automation Administration (AFA) tool. The AFA tool enables multiple financial institutions to log into FAMS at the same time and provides a mechanism for each financial institution to set up some of its key data, such as fee structure, settings, and messaging. The AFA tool is a step-by-step process that separates the technical specifications of each financial institution from the financial institution data that is specifically based on its business decisions.

[0164] Some of the financial institution’s information can be opened to financial institutions primarily based on administrative roles to access the AFA tool. Once submitted, this information can be automatically uploaded to the designated FAMS “tenant” (such as the financial institution). Certain configurable data points can be opened to qualified financial institution employees for maintenance.

[0165] Data points for each financial institution may include: service fees, convenience fees (in dollars or as a percentage), business rules based on various criteria, messaging, brand identity (colors / logos), return item codes, NSF / OF fee refund matrix, settlement ledger, time zone, website, primary phone number, group fraud email, courtesy payment plan name, contact center name, customer portal start time, end time, mission control portal start date, end date, service fee discounts, holiday schedule, workday schedule, billing address, and billing contact.

[0166] Data points for technical teams can include: Member portal; URL, Okta client ID – Mission Control; URL, Okta client OD, Group ID – Credit Union; Core API, Transaction API, Database connection string, Database name – Sendgrid; API key, From email address, URL, From name – Twillio; SID token, Phone – Payment details; Key, Access key, Public profile – Service Bus endpoint – Azure Storage account details; Storage account endpoint, Blob path for Extract, Transform, and Load (ETL) triggers – Secure File Transfer Protocol (SFTP) details; Host, Port, Username, Password, Path – Decision code; ACH payment, Fraud, Money order, Payment, Fraud.

[0167] A role for the AFA tool may include a role name and a role description. Configuration may include financial information, convenience fee threshold, transaction fee threshold, FAMS fee threshold, administrator email, and IDP configuration.

[0168] The AFA tool also includes sections that display the following: Dashboard, Company Setup Users, Tenants, and Setup. Additional data fields can be added as financial institution requirements change, such as including specific messaging throughout the technology, processing codes (such as GL codes, return codes, and similar codes) discounts, business rule standards, and analytics.

[0169] Customer Settings

[0170] Currently, financial institutions do not offer customers customer settings to configure their interfaces and processes to make them more convenient for daily use, nor do they provide enough flexibility to create settings that suit customers' financial and daily needs. Without these settings, customers cannot establish alerts, payment settings, automated decisions, or other processing that makes technology more convenient and easier to use.

[0171] In some embodiments, FAMS opens these customer settings functions to customers. Customer settings can be specific to each customer, and may allow certain processes to be established to automatically help customers. These settings can be configured by the customer and can be saved by the customer until updated. Example settings include alarm time, secondary alarm, preferred payment method, automatic decision-making for certain types of payments, amount warning, suspicious payee warning, overdraft warning, communication preferences, updated contact information, emergency backup plan template settings, and nickname accounts. Because FAMS works "inside the vault door" (after customer authentication occurs), these settings are considered safe relative to the authentication process of pre-approved financial institutions, and can be updated to the core system used by financial institutions.

[0172] Work Notice

[0173] Job opportunities are everywhere and easily accessible. However, in the financial institution space, job opportunity notifications have never been a part of financial institutions’ offerings, despite their immense benefits to consumers, especially those with financial problems. Constant notifications of job opportunities would be helpful and convenient for those who are struggling financially.

[0174] In some embodiments, FAMS provides such job alerts. By providing job alerts in a convenient and familiar portal (where customers currently bank), FAMS provides customers with a "one-stop" financial arena to handle all of their financial needs. Online banking is a primary financial institution tool used by consumers and small businesses. Since the job alerts tab is located within the online banking tab, consumers can conveniently view local job openings while they are doing online banking.

[0175] FAMS can use algorithms and rules to determine which jobs are available based on criteria collected from activity in the customer's checking account and responses to overdraft / NSF program related activities. This criteria can include past positions and employers, work location, and legal working age. In addition, FAMS can aggregate job notices posted on various websites and display jobs in one place that appear to match jobs that the consumer has held historically. These data points, along with weighted scores, can be used to calculate the best job for each customer. FAMS can also provide customers with the ability to expand their search by providing additional information. In some embodiments, FAMS does not maintain this additional information.

[0176] Fig. 20 A block diagram of an example computer system 2000 is depicted in which embodiments described herein may be implemented. The computer system 2000 includes a bus 2002 or other communication mechanism for communicating information, one or more hardware processors 2004 coupled to the bus 2002 for processing information. The hardware processor(s) 2004 may be, for example, one or more general purpose microprocessors.

[0177] The computer system 2000 also includes a main memory 2006, such as a random access memory (RAM), a cache, and / or other dynamic storage device, coupled to the bus 2002 for storing information and instructions to be executed by the processor 2004. The main memory 2006 may also be used to store temporary variables or other intermediate information during execution of instructions to be executed by the processor 2004. When stored in a storage medium accessible to the processor 2004, these instructions present the computer system 2000 as a special-purpose machine that is customized to perform the operations specified in the instructions.

[0178] The computer system 2000 also includes a read only memory (ROM) 2008 or other static storage device coupled to the bus 2002 for storing static information and instructions for the processor 2004. A storage device 2010, such as a magnetic disk, optical disk, or USB thumb drive (flash drive), is provided and coupled to the bus 2002 for storing information and instructions.

[0179] The computer system 2000 can be coupled to a display 2012, such as a liquid crystal display (LCD) (or touch screen), via the bus 2002 for displaying information to a computer user. An input device 2014, including alphanumeric and other keys, is coupled to the bus 2002 for communicating information and command selections to the processor 2004. Another type of user input device is a cursor controller 2016, such as a mouse, trackball, or cursor direction keys, for communicating direction information and command selections to the processor 2004 and for controlling cursor movement on the display 2012. In some implementations, the same direction information transmission and command selection as a cursor controller can be achieved by receiving touch operations on a touch screen without a cursor.

[0180] The computing system 2000 may include a user interface component to implement a graphical user interface GUI, which may be stored in a mass storage device as executable software code executed by (one or more) computing devices. This component and other components may include, by way of example, components such as software components, object-oriented software components, class components and task components, processes, functions, properties, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, and variables.

[0181] In general, the words "component", "engine", "system", "database", "data storage", etc. used herein may refer to logic embodied in hardware or firmware, or to a set of software instructions written in a programming language (such as Java, C or C++) that may have entry and exit points. Software components can be compiled and linked into executable programs installed in dynamic link libraries, or can be written in interpreted programming languages ​​(such as BASIC, Perl or Python). It should be understood that software components can be called by other components or by themselves, and / or can be called in response to detected events or interrupts. Software components configured for execution on a computing device can be stored on a computer-readable medium (such as a compact disc, digital video disc, flash drive, disk, or any other tangible medium), or provided as a digital download (and can be initially stored in a compressed or installable format that requires installation, decompression or decryption before execution). Such software code can be stored in part or in whole on a storage device of the executing computing device for execution by the computing device. Software instructions can be embedded in firmware, such as an EPROM. It should also be understood that hardware components may be composed of connected logic units (such as gates and flip-flops) and / or may be composed of programmable units (such as programmable gate arrays or processors).

[0182] The computer system 2000 may implement the techniques described herein using custom hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic that, in combination with the computer system, make the computer system 2000 into or program the computer system 2000 into a special purpose machine. According to one embodiment, the techniques herein are performed by the computer system 2000 in response to the processor(s) 2004 executing one or more sequences of one or more instructions contained in the main memory 2006. Such instructions may be read into the main memory 2006 from another storage medium such as the storage device 2010. Execution of the sequences of instructions contained in the main memory 2006 causes the processor(s) 2004 to perform the process steps described herein. In alternative embodiments, hardwired circuitry may be used in place of or in combination with software instructions.

[0183] As used herein, the term "non-transitory medium" and similar terms refer to any medium that stores data and / or instructions that cause a machine to operate in a particular manner. Such non-transitory media may include non-volatile media and / or volatile media. Non-volatile media include, for example, optical or magnetic disks, such as storage device 2010. Volatile media include dynamic memory, such as main memory 2006. Common forms of non-transitory media include, for example, floppy disks, diskettes, hard disks, solid-state drives, magnetic tapes, or any other magnetic data storage medium, CD-ROMs, any other optical data storage medium, any physical medium with a pattern of holes, RAM, PROM, and EPROM, FLASH-EPROM, NVRAM, any other memory chip or storage cartridge, and network versions thereof.

[0184] Non-transitory media are distinct from, but may be used in conjunction with, transmission media. Transmission media participate in the transfer of information between non-transitory media. For example, transmission media include coaxial cables, copper wire, and optical fiber, including the wires that make up bus 2002. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0185] Computer system 2000 also includes a communication interface 2018 connected to bus 2002. Network interface 2018 provides a two-way data communication connected to one or more network links, and the network link is connected to one or more local networks. For example, communication interface 2018 can be an integrated services digital network (ISDN) card, a cable modem, a satellite modem or a modem provided to connect to the data communication of a telephone line of the corresponding type. As another example, network interface 2018 can be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or a WAN component with a WAN communication). Wireless links can also be implemented. In any such implementation, network interface 2018 sends and receives an electrical signal, an electromagnetic signal or an optical signal carrying a digital data stream representing various types of information.

[0186] A network link typically provides data communications to other data devices through one or more networks. For example, a network link may provide a connection to a host computer or to data devices operated by an Internet Service Provider (ISP) through a local network. In turn, the ISP provides data communications services through the global packet data communications network now commonly referred to as the "Internet." Both local area networks and the Internet use electrical, electromagnetic, or optical signals that carry digital data streams. The signals through the various networks, as well as the signals on the network link and the signals through the communication interface 2018 are example forms of transmission media that transfer digital data to and from the computer system 2000.

[0187] Computer system 2000 can send messages and receive data, including program code, through the network(s), network links, and communications interface 2018. In the Internet example, a server can transmit the requested code for an application program through the Internet, an ISP, a local network, and communications interface 2018.

[0188] The received code may be executed by processor 2004 as it is received, and / or stored in storage device 2010 or other non-volatile storage for later execution.

[0189] Each of the processes, methods, and algorithms described in the preceding sections may be embodied in a code component executed by one or more computer systems or computer processors including computer hardware, and fully or partially automated by it. One or more computer systems or computer processors may also be run in a "cloud computing" environment or as "software as a service" (SaaS) to support the execution of related operations. These processes and algorithms may be implemented in part or in whole in a dedicated circuit. The various features and processes described above may be used independently of each other, or may be combined in various ways. Different combinations and sub-combinations are intended to fall within the scope of the present invention, and certain method or process steps may be omitted in some implementations. The methods and processes described herein are also not limited to any particular order, and the steps or states associated therewith may be executed in other appropriate orders, or may be executed in parallel, or in some other manner. Steps or states may be added to or deleted from the disclosed example implementations. The execution of certain operations or processes may be distributed among computer systems or computer processors that reside not only in a single machine, but also on multiple machines.

[0190] As used herein, circuits can be implemented using any form of hardware, or a combination of hardware and software. For example, one or more processors, controllers, application specific integrated circuits (ASICs), programmable logic arrays (PLAs), programmable array logic (PALs), complex programmable logic devices (CPLDs), field programmable gate arrays (FPGAs), logic components, software routines, or other mechanisms can be implemented to form circuits. In implementation, various circuits described herein can be implemented as discrete circuits, or the functions and features described can be partially or completely shared between one or more circuits. Although various features or functional elements can be described or claimed as independent circuits separately, these features and functions can be shared between one or more common circuits, and this description should not require or imply that independent circuits are needed to implement these features or functions. In the case where the circuit is implemented in whole or in part using software, this software can be implemented as operating together with a computing or processing system (such as computer system 2000) that can perform the functions described therefor.

[0191] As used herein, the term "or" may be interpreted as being inclusive or exclusive. In addition, the singular description of a resource, operation, or structure should not be interpreted as excluding the plural. Unless otherwise specifically stated or understood otherwise in the context of use, conditional language, such as "may," "might," "might," or "can," is generally intended to convey that some embodiments include, while other embodiments do not include, certain features, elements, and / or steps.

[0192] Unless expressly stated otherwise, the terms and phrases used herein and variations thereof should be construed as open ended, not restrictive. Adjectives such as "traditional," "conventional," "normal," "standard," "known," and terms of similar meaning should not be construed to limit the items described to items available in a given time period or at a given time, but should be understood to include traditional, conventional, normal, or standard technologies that may be available or known at any time now or in the future. In certain cases, the presence of broad words and phrases such as "one or more," "at least," "but not limited to," or other similar phrases should not be interpreted as an intent or requirement to use a narrower context where such broad phrases may not exist.

Claims

1. A system for providing alarm management and real-time remediation capabilities, the system comprising: one or more hardware processors; and a non-transitory machine-readable storage medium encoded with instructions executable by the one or more hardware processors to perform operations comprising: Receiving, by a computer processor, an electronic file, wherein the electronic file comprises: an overdraft information data structure, the overdraft information data structure comprising overdraft information representing one or more overdraft events and customers associated with the overdraft events; and a contact information data structure, the contact information data structure comprising an electronic address for each customer; In response to obtaining the overdraft limit information, the computer processor automatically resolves the overdraft limit information into an overdraft limit event of the customer associated with the overdraft limit event; For one or more of said Customers: generating, by the computer processor, an overdraft notification message and sending the overdraft notification message to an electronic address of the customer, wherein the overdraft notification message includes a link to an authentication interface of an institution associated with the customer; providing, by the computer processor, a user interface to a consumer electronic device for display to the consumer, in response to the consumer being authenticated by the authentication interface, wherein the user interface displays overdraft information for each overdraft event associated with the consumer and display elements from which a user can select, including a display element for a payment option; and In response to the customer selecting the payment option, a payment message is generated and sent by the computer processor, wherein the payment message results in a transfer of funds to the institution.

2. The system according to claim 1, wherein: Each overdraft event represents an overdraft event in a financial account of a customer of the institution, the overdraft information indicating a paid negotiable financial instrument opened on the financial account, wherein a monetary amount of the paid negotiable financial instrument exceeds an available monetary balance of the financial account but does not exceed an overdraft amount of the financial account.

3. The system of claim 2, wherein the operations further comprise: identifying the negotiable financial instrument in the user interface with a service fee and an amount due corresponding to an amount by which the monetary amount of the negotiable financial instrument exceeds the available monetary balance of the financial account; as well as A plurality of action options are provided in the user interface, wherein the action options include an option for paying the amount due.

4. The system of claim 3, wherein the operations further comprise: in response to said customer selecting said displayed negotiable financial instrument and said option for payment, displaying a plurality of payment methods; as well as In response to the customer selecting one of the payment methods, a payment is initiated to the financial account according to the selected payment method.

5. The system of claim 3, wherein the operations further comprise: determining a period within which the customer can remedy the overdraft event; as well as A user interface is generated for said display to a customer, the user interface providing an indication of said deadline.

6. The system of claim 5, wherein the operations further comprise: In response to the expiration of the time limit, generating a user interface for display to the customer in which an indication of the expiration of the time limit is provided and the payment option is disabled or deleted.

7. The system of claim 5, wherein the operations further comprise: One or more rules are processed to determine at least one of the service fee and the term.

8. A non-transitory machine-readable storage medium encoded with instructions executable by one or more hardware processors of a computing component for providing alarm management and real-time remediation functionality, the machine-readable storage medium comprising instructions for causing the one or more hardware processors to perform operations comprising: Receiving, by a computer processor, an electronic file, wherein the electronic file comprises: an overdraft information data structure, the overdraft information data structure comprising overdraft information representing one or more overdraft events and customers associated with the overdraft events; and a contact information data structure, the contact information data structure comprising an electronic address for each customer; In response to obtaining the overdraft limit information, the computer processor automatically resolves the overdraft limit information into an overdraft limit event of the customer associated with the overdraft limit event; For one or more of said Customers: generating, by the computer processor, an overdraft notification message and sending the overdraft notification message to an electronic address of the customer, wherein the overdraft notification message includes a link to an authentication interface of an institution associated with the customer; providing, by the computer processor, a user interface to a consumer electronic device for display to the consumer, in response to the consumer being authenticated by the authentication interface, wherein the user interface displays overdraft information for each overdraft event associated with the consumer and display elements from which a user can select, including a display element for a payment option; and In response to the customer selecting the payment option, a payment message is generated and sent by the computer processor, wherein the payment message results in a transfer of funds to the institution.

9. The medium according to claim 8, wherein Each overdraft event represents an overdraft event in a financial account of a customer of the institution, the overdraft information indicating a paid negotiable financial instrument opened on the financial account, wherein a monetary amount of the paid negotiable financial instrument exceeds an available monetary balance of the financial account but does not exceed an overdraft amount of the financial account.

10. The medium of claim 9, the operations further comprising: identifying the negotiable financial instrument in the user interface with a service fee and an amount due corresponding to an amount by which the monetary amount of the negotiable financial instrument exceeds the available monetary balance of the financial account; as well as A plurality of action options are provided in the user interface, wherein the action options include an option for paying the amount due.

11. The medium of claim 10, the operations further comprising: in response to said customer selecting said displayed negotiable financial instrument and said option for payment, displaying a plurality of payment methods; as well as In response to the customer selecting one of the payment methods, a payment is initiated to the financial account according to the selected payment method.

12. The medium of claim 10, the operations further comprising: determining a period within which the customer can remedy the overdraft event; as well as A user interface is generated for said display to a customer, the user interface providing an indication of said deadline.

13. The medium of claim 12, the operations further comprising: In response to the expiration of the time limit, a user interface is generated for display to the customer in which an indication of the expiration of the time limit is provided and a payment option is disabled or deleted.

14. The medium of claim 12, the operations further comprising: One or more rules are processed to determine at least one of the service fee and the term.

15. A method for providing alarm management and real-time remediation functionality via a computer processor programmed with computer executable instructions, the method comprising: receiving, by the computer processor, an electronic file, wherein the electronic file comprises: an overdraft information data structure, the overdraft information data structure comprising overdraft information representing one or more overdraft events and customers associated with the overdraft events; and a contact information data structure, the contact information data structure comprising an electronic address for each customer; In response to obtaining the overdraft limit information, the computer processor automatically resolves the overdraft limit information into an overdraft limit event of the customer associated with the overdraft limit event; For one or more of said Customers: generating, by the computer processor, an overdraft notification message and sending the overdraft notification message to an electronic address of the customer, wherein the overdraft notification message includes a link to an authentication interface of an institution associated with the customer; providing, by the computer processor, a user interface to a consumer electronic device for display to the consumer, in response to the consumer being authenticated by the authentication interface, wherein the user interface displays overdraft information for each overdraft event associated with the consumer and display elements from which a user can select, including a display element for a payment option; and In response to the customer selecting the payment option, a payment message is generated and sent by the computer processor, wherein the payment message results in a transfer of funds to the institution.

16. The method according to claim 15, wherein: Each overdraft event represents an overdraft event in a financial account of a customer of the institution, the overdraft information indicating a paid negotiable financial instrument opened on the financial account, wherein a monetary amount of the paid negotiable financial instrument exceeds an available monetary balance of the financial account but does not exceed an overdraft amount of the financial account.

17. The method according to claim 16, further comprising: identifying the negotiable financial instrument in the user interface with a service fee and an amount due corresponding to an amount by which the monetary amount of the negotiable financial instrument exceeds the available monetary balance of the financial account; as well as A plurality of action options are provided in the user interface, wherein the action options include an option for paying the amount due.

18. The method according to claim 17, further comprising: in response to said customer selecting said displayed negotiable financial instrument and said option for payment, displaying a plurality of payment methods; as well as In response to the customer selecting one of the payment methods, a payment is initiated to the financial account according to the selected payment method.

19. The method according to claim 17, further comprising: determining a period within which the customer can remedy the overdraft event; generating a user interface for said display to a customer, the user interface providing an indication of said deadline; as well as In response to the expiration of the time limit, generating a user interface for display to the customer in which an indication of the expiration of the time limit is provided and the payment option is disabled or deleted.

20. The method according to claim 19, further comprising: One or more rules are processed to determine at least one of the service fee and the term.

Images