Real-time alert management system for integration and remediation of overdraft generating systems

Abstract

Embodiments provide a system for alert management and real-time remediation. The system receives an electronic file including an overdraft authorization information data structure containing overdraft authorization information, and automatically parses the overdraft authorization information to obtain overdraft authorization events for an associated customer. The system sends an overdraft authorization notification message to the associated customer. The message may include a link to an authentication interface of an institution associated with the customer. Once the customer is authenticated, the system provides a user interface that displays the overdraft authorization information and a display element of a payment option for each overdraft authorization event associated with the customer. In response to the customer selecting a payment option, the system sends a payment message to effect a payment to the institution.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority to U.S. Patent Application No. 17 / 860,611 (filed July 8, 2022), which is incorporated herein by reference in its entirety.

[0002] This application is related to U.S. Patent Application Publication No. US 2015 / 0026060 A1 [Abandoned] (filing date: July 7, 2014, title: "FINANCIAL ALERT MANAGEMENT SYSTEM HAVING A MOBILE INTERFACE"), the entire disclosure of which is incorporated herein by reference.

[0003] This application is also related to U.S. Patent No. 11,144,917 B1 (issued October 12, 2021, entitled "ALERT MANAGEMENT SYSTEM WITH REAL-TIME REMEDIATION AND INTEGRATION WITH THE EXCEPTION ORIGINATING SYSTEM"), the entire disclosure of which is incorporated herein by reference.

[0004] A technology platform for managing time-sensitive exception notifications in real time and integrating with overdraft allowance accrual systems. [Background technology]

[0005] Various technologies exist for providing alerts to users. Existing technologies have various technical problems and shortcomings. Even when alerts are provided, they often lack a technical mechanism for users to take action. Furthermore, when there are multiple parties involved, a drawback is that users cannot take action and the necessary updates cannot be made to all parties' systems in real time. When an entity restricts access to a computer system, such as a server, users may need to manually notify the entity of the action they are taking. This is a limitation of the technology, especially when users need to receive an alert, take action, and have the entity, with limited access to the system, update based on the action taken as soon as possible. While existing systems often have a function for manually notifying the entity, this is ineffective when there is a time-sensitive deadline. These and other technical problems exist.

[0006] Alert management systems are applicable across many industries and have many practical applications. One practical application, but not limited to, is in various FinTech solutions. Specifically, various technologies exist to help customers receive notifications about actions to be taken regarding their financial and other accounts. These technologies have drawbacks, including those mentioned above. Furthermore, the technical challenges of existing systems in the FinTech space are exacerbated by regulations, complexity, and the multiple parties involved in the systems. Examples of such systems are numerous.

[0007] By way of example only, the following describes, technically and otherwise, what happens when a negotiable instrument (e.g., a check or an Automated Clearing House (ACH) refund) is not authorized by the financial institution associated with the account to which the negotiable instrument is being refunded, i.e., the payer's bank.

[0008] Even if a negotiable instrument is issued, it may not be accepted by the financial institution associated with the account to which it is being redeemed, i.e., the payor's bank, for a variety of reasons. One reason is that there are insufficient funds in the account to which the negotiable instrument is being redeemed. This is commonly referred to as a Not Sufficient Funds (NSF) event. Similarly, when funds credited to an account have not yet settled (i.e., the funds are unavailable), this is commonly referred to as an Uncollected Funds (UCF) event. Unless otherwise noted, both NSF and UC events are collectively referred to as NSF events.

[0009] Reasons for insufficient funds include an account being overdrawn (i.e., an overdraft occurs, resulting in withdrawals from the account that cause the account's available balance to fall below zero), or the amount shown on the negotiable instrument exceeds the account's available balance, resulting in a balance greater than zero but less than the amount shown on the negotiable instrument. Because checks, drafts, substitute checks, and ACH withdrawals are negotiable instruments processed using standard payment methods and differ from other transactions, such as ATM withdrawals, on-the-go check and draft cashing, and point-of-sale transactions, which are authorized and settled at the time of transaction, the financial institution associated with the account may refuse payment on the negotiable instrument (in this example, an unauthorized withdrawal request) and return the negotiable instrument as unpaid.

[0010] Unfortunately, while a payer financial institution may refuse to pay on a negotiable instrument issued for insufficient funds, in reality, the holder of the negotiable instrument (i.e., the payee) does not physically visit the payer financial institution to cash the negotiable instrument, but instead deposits a check into his or her account (i.e., the payee's account) at another financial institution, and the payer financial institution processes the transaction by the next day and automatically pays / credits the amount written on the negotiable instrument to the payee's account. Only then, upon processing the settlement, does the payer financial institution learn that the negotiable instrument has in fact triggered an NSF event (also known as an NSF occurrence).

[0011] On the payer side, the payer's financial institution creates and issues an NSF notice. When the payee's financial institution returns the check in a check return file, the payee's financial institution refunds the amount received minus a risk-incurring fee. In addition, the payer's financial institution disapproves the negotiable instrument, sends the payer an NSF notice by first class mail, and charges the payer a fee for creating a "bad" negotiable instrument.

[0012] On the payee side, the payee will receive a Returned Deposited Item (RDI) notice and will typically be charged a fee by the payee's financial institution for the negotiable instrument. Furthermore, since the payee may be issuing negotiable instruments based on the payer's negotiable instrument, the potential for non-performing instruments to snowball.

[0013] At this point, it becomes the payee's sole responsibility to recover from the payor the unpaid amount due on the negotiable instrument and any associated penalties, costs, and fees. As a result, the payee may pursue legal action against the payor. Additionally, the payee's financial institution may report the payor to a database of bad check issuers, such as Check Connection, TeleCheck, Shared Check Authorization Network ("SCAN"), or ChexSystems. Finally, knowingly passing a "bounced check" is a crime in most states and is subject to various criminal penalties.

[0014] Each business day, all depository financial institutions reconcile their accounts with the corresponding negotiable instruments received the previous business day and create an Exception Information (EI). The EI may identify all transactions presented the previous day that resulted in a negative balance, or it may identify only the items that resulted in a negative balance. The EI is typically updated with information about the corresponding account and corresponding account holder each time an NSF occurs. In addition, each financial institution may flag when an overdraft authorization / courtesy pay occurs. In the following discussion, each EI may be updated with information that flags when an overdraft authorization / courtesy pay occurs.

[0015] To better understand the above-mentioned problems, the following detailed description will be provided with reference to FIG. 1. FIG. 1 is a block diagram illustrating an example of a known payment method using a negotiable instrument 100 between two parties. The negotiable instrument 100 may be any type of negotiable instrument, such as a transaction check, ACH, POS, or draft. In this example, the first party is a payer 102 and the second party is a payee 104. The payer 102 has a payer account 106 with a payer financial institution (FI) 108. The payee 104 has a payee account 110 with a payee financial institution (FI) 112. In this example, the payer FI 108 and the payee FI 112 are in signal communication with each other via a signal path 114 that may include any known communication network 116. The communication network 116 may be a computer network, such as the Internet, or a proprietary secure network. The signaling path 114 between the Payor FI 108 and the Payee FI 112 may include a Payor Computer Server 118 (at the Payor FI 108) and a Payee Computer Server 120 (at the Payee FI 112). The Payor 102, the Payee 104, or both may be businesses or individuals. The Payor Account 106, the Payee Account 110, or both may be checking accounts. The communication network 116 may be in signal communication with a regional Federal Reserve Bank 117.

[0016] In one example of operation, the payor 102 creates 122 a negotiable instrument 100 bearing an amount and physically or electronically delivers it to the payee 104. In this example, the negotiable instrument 100 is drawn on the payor account 106. In this example, the payor 102 is the "Drawer" of the payor account 106, and the payor FI 108 is the "Drawee" because presenting the negotiable instrument 100 at the payor FI 108 enables payment from the payor account 106. The payee 104 physically or electronically deposits the negotiable instrument 100 in the payee account 110. Once the negotiable instrument 100 is deposited in the payee account 110, the payee FI 112 can present the negotiable instrument 100 to the payor FI 108 for payment via a signal path 114, which includes the communications network 116. In response, the Payor FI 108 remits a payment 132 in the amount set forth on the negotiable instrument 100 via the Payor Computer Server 118. The Payor FI 108 may utilize the Check21 System or other interbank transaction systems.

[0017] In this example, when the payer FI 108 sends a payment 132 to the payee FI 112, the payer FI 108 withdraws funds from the payer account 106 to determine whether sufficient funds are available in the payer account 106 to pay the amount listed on the negotiable instrument 100. If the funds are available in the payer account 106, the amount listed on the negotiable instrument 100 is withdrawn from the payer account 106, completing the payment 132 by the payer FI 108. Alternatively, if the payer FI 108 determines that the payer account 106 does not have sufficient funds to pay the amount listed on the negotiable instrument 100, the clearing process designates the negotiable instrument 100 as an NSF trigger and includes an NSF item in the EI generated by the payer FI 108 the next day. In this example, the clearing process may 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 a separate, independent computer system of the payer FI 108. The reconciliation system 134 may include software containing rules and a decision engine / module for reconciling amounts paid on behalf of the payer 102 with funds available in the payer account 106. The reconciliation system 134 may access the payer FI 108's customer list and corresponding accounts to generate the daily EI 136. The daily EI 136 includes either all presented negative balance items or all NSF occurrences, along with the corresponding negotiable instruments that caused the NSF occurrences, the accounts corresponding to the negotiable instruments, and the customer information corresponding to the accounts. The generated EI 136 may be received and reviewed by an administrator 138 of the payer FI 108.

[0018] In some exceptional cases, the administrator 138 finds that the payer 102 is listed on the EI 136 because an NSF has occurred due to the negotiable instrument 100. The administrator 138 subjectively considers the payer 102 to be a valued or preferred customer of the payer FI 108. In some cases, the administrator 138 may, at their discretion, have the payer FI 108 pay the negotiable instrument 100. Because the negotiable instrument is marked "paid," an NSF notice 139 is sent to the payer 102 if the balance is still insufficient, and the payee FI 112 does not receive an NSF item in its returned items file.

[0019] As another example, a representative of an FI 108, such as the custodian 138, may notify the payer 102 that the negotiable instrument 100 listed on the EI needs to be settled. To settle the negotiable instrument 100, the payer must make a payment directly to the custodian or designee. The custodian or designee must locate the NSF record in the payer FI's 108 system and manually mark the negotiable instrument 100 as "paid."

[0020] However, if the Payer 102 does not deposit the funds within the time allowed by the Payer FI 108, the Payer FI 108 marks the item as NSF in the returned check file and sends it to the Payee FI 112.

[0021] As mentioned above, this process is very time-sensitive and manual. If the payer does not pay the required amount within the time frame set by the FI, the payer will be recorded as an NSF incurrence, and the negotiable instrument that caused the NSF will be rejected and returned for insufficient funds. Furthermore, even if the payer initiates payment of the required amount within the time frame set by the FI, the payment may not settle before the time frame set by the FI has elapsed, resulting in the same outcome. Summary of the Invention [Means for solving the problem]

[0022] In one aspect, the present invention provides an improved technology platform for a Financial Alert Management and Rapid Remediation System (FAMS), which may include some or all of the technical components and features described below.

[0023] A FAMS includes a set of computer software modules (running on a processor) that generate alerts, also referred to herein as notifications, that enable customers to manage and control outcomes within a specified timeframe based on their decisions and actions in a real-time environment. FAMS provides a technological solution that leverages real-time communications to enable customers, both individuals and businesses, to take action to minimize expenses that would otherwise be incurred and protect their credit standing, reputation, and identity. FAMS also provides a protected and secure means to communicate information, remediate situations, and provide options in the customer's best interest in real time.

[0024] The FI electronically creates an exception information (EI) describing one or more events (e.g., an NSF event, etc.) and automatically submits the EI to the platform. The system may configure the EI to have a specific data structure. One component of the data structure may include information about a specific rule that applies to a specific event contained in the EI. The rule may be based on a set of information related to the specific event and a set of rules in a rules database. Thus, the rule may be different for each event. The platform parses the EI into events, processes the EI events according to the rules, and generates a customized electronic notification with a link for the customer. The customer can use this link to access the platform, for example, by running a browser on their device, and authenticate using a single sign-on (SSO) feature associated with their account with the FI. After authentication, the FI's SSO interface may redirect the customer's browser to the platform. The platform generates a user interface to display the event, the deadline for response, the options for possible actions (e.g., payment, reporting fraud, returning outstanding negotiable instruments), fees associated with the action (which may vary for each user based on rules associated with each event), and, if payment is selected as the action, one or more payment options (including options that allow the user to make payment directly on the platform without using a separate website or application).

[0025] After reviewing the exception notification, the customer may select an action on a user interface that presents options, such as making a payment to address the event. If the customer selects a payment action, the platform seamlessly communicates the customer's selection and payment information received from the customer to the FI in real time, allowing for fast and automatic posting of the payment directly to the customer's account without further manual intervention.

[0026] FAMS reduces the occurrence of non-payment events, such as when a payor FI refuses to pay a negotiable instrument created by a payor that has a payor account with the payor FI, resulting in a non-sufficient funds (NSF) event because the amount of the negotiable instrument exceeds the amount of available funds in the payor account.

[0027] The FAMS may include a communication module, a database, a timing module, a second communication module, a determination module, a payment module, and a settlement module. A controller may be in signal communication with the first communication module, the second communication module, the payment module, the timing module, and the database. The controller is configured to control operation of the system. The first communication module is configured to receive from the payer FI an EI, payer contact data, and an FI predetermined time period. The payer FI creates an EI that includes all events that ultimately resulted in a negative balance as a result of nightly processing.

[0028] The payer contact data includes payer contact information and an FI predetermined period for receiving funds to avoid an NSF event so that a non-payment event in which the payer FI refuses to pay the negotiable instrument does not occur. The database is configured to utilize the payer contact information based on the payer contact data to accumulate NSF events based on the EI. The timing module is configured to generate a FAMS period based on the FI predetermined period. The second communication module is configured to attempt to contact the payer based on the payer contact information and, if contacted, to inform the payer of the NSF event and, if contacted, to inform the payer of the NSF event and provide options for taking action to change the order of events by selecting "pay," "return," or "fraud" and / or by paying the amount required to remedy the NSF event. The payment module is configured to receive payment from the payer.

[0029] In one example of operations, the system executes a method for reducing the occurrence of non-payment events, such as when a payer FI refuses to pay a negotiable instrument created by the payer or when the amount of the negotiable instrument exceeds available funds in the payer account, resulting in an NSF event. The method may include, for example, receiving (electronically) from the payer FI (e.g., as a data structure) an EI that includes payer contact data, FI predetermined time periods, rules, and / or other data, parsing the data structure to extract various components, storing a data item of the EI that includes the NSF event, and storing payer contact information based on the payer contact data.

[0030] The method may further include generating a FAMS term based on the FI predetermined term and attempting to contact the payer based on the payer's contact information. If contact is made, the method may include communicating the NSF event, options for taking action, an amount required to remediate the NSF event, and the FAMS term to the payer in real time. The method may include receiving payment from the payer. [Brief explanation of the drawings]

[0031] The present disclosure, in accordance with one or more various embodiments, will now be described in detail with reference to the following drawings, which are for illustrative purposes only and depict only typical or exemplary embodiments.

[0032] [Figure 1] 1 is a block diagram showing an example of a known method of payment between two persons using a negotiable instrument 100. FIG.

[0033] [Figure 2] FIG. 1 is a block diagram illustrating a financial system in accordance with some embodiments of the disclosed technology.

[0034] [Figure 3]1 is a flowchart illustrating a process for a customer to manage overdraft authorization or courtesy pay items (collectively referred to herein as "overdraft authorization events") on their account at a financial institution, in accordance with some embodiments of the technology disclosed herein.

[0035] [Figure 4] 1 illustrates an example of a user interface that may be provided to a customer in accordance with some embodiments of the disclosed technology.

[0036] [Figure 5] 1 is a flowchart illustrating a process for pricing overdraft fees from a pricing model grid, in accordance with some embodiments of the disclosed technology.

[0037] [Figure 6] 1 illustrates an example of a first user interface that may be provided to a customer to facilitate selection of a process, in accordance with some embodiments of the disclosed technology.

[0038] [Figure 7] 10 illustrates an example of a second user interface that may be provided to a customer to facilitate selection of a process, in accordance with some embodiments of the disclosed technology.

[0039] [Figure 8] 1 illustrates an example of a user interface that may be provided to a customer to enable an AI to make decisions based on past activity, in accordance with some embodiments of the disclosed technology.

[0040] [Figure 9] 1 illustrates an example of a user interface that may be provided to a customer for analyzing available payments in accordance with some embodiments of the disclosed technology.

[0041] [Figure 10] 1 illustrates an example of a user interface that may be provided to a customer by a savings estimator tool, in accordance with some embodiments of the disclosed technology.

[0042] [Figure 11] 1 illustrates an example of a user interface that may be provided to a customer for analysis of achieved savings, in accordance with some embodiments of the disclosed technology.

[0043] [Figure 12] 1 is a flowchart illustrating the operation of a real-time bank-issued check fraud prevention tool in accordance with some embodiments of the disclosed technology.

[0044] [Figure 13] 1 is a flowchart illustrating the operation of a real-time fraud item reporting tool in accordance with some embodiments of the disclosed technology.

[0045] [Figure 14] 1 illustrates an example of a user interface that may be provided to a customer by a real-time fraud item reporting tool, in accordance with some embodiments of the disclosed technology.

[0046] [Figure 15] 1 is a flowchart illustrating a debit card automatic opt-in process in accordance with some embodiments of the disclosed technology.

[0047] [Figure 16] 1 is a flowchart illustrating a process for providing ACH warehouse analytics in accordance with some embodiments of the disclosed technology.

[0048] [Figure 17] 1 illustrates an example of a user interface that a customer may employ to request an ACH accumulation analysis, in accordance with some embodiments of the disclosed technology.

[0049] [Figure 18] 1 illustrates an example of a user interface that may be provided to a customer by a real-time fraud item reporting tool, in accordance with some embodiments of the disclosed technology.

[0050] [Figure 19] 1 is a flowchart illustrating a process for automatic GL matching in accordance with some embodiments of the technology disclosed herein.

[0051] [Figure 20] 1 is an example of a computing component that may be used to implement features of the embodiments described in this disclosure.

[0052] The drawings are not intended to be exhaustive or to limit the disclosure to the precise form disclosed. DETAILED DESCRIPTION OF THE INVENTION

[0053] Embodiments of the technology disclosed herein include a Financial Alert Management and Immediate Remediation System (FAMS) that cooperates with one or more FIs, one or more customer electronic devices, and one or more external payment provider systems. In disclosed embodiments, the FAMS is a system separate from the payer FI. For example, as described herein, the FAMS may include a server programmed with computer instructions that can be operated to provide services to various financial institutions. In other embodiments, some or all of the elements of the FAMS may be provided and / or operated by the payer FI as part of the payer FI's internal systems. The payer FI may be a bank, savings and loan association, credit union, trust company, mortgage company, or similar financial institution. The external payment provider may be, for example, a credit card company, online payment company, or similar financial institution.

[0054] A FAMS may include a server programmed with a set of software modules that allow customers to manage and control outcomes based on their decisions and actions in a real-time environment within a specified time period. The software modules also include intelligent data analysis that derives scores based on current and historical data from various input sources. A FAMS allows customers, both individuals and businesses, to take action to minimize expenses that would otherwise be incurred and to protect their credit standing, reputation, and identity. It also provides a protected and secure means to communicate information, remediate situations, and provide options in the customer's best interest in real time.

[0055] Figure 2 is a block diagram illustrating a financial system 200 in accordance with some embodiments of the disclosed technology. Referring to Figure 2, the financial system 200 may include a real-time remediation financial alert management system (FAMS) 204 in network communication (e.g., via a network 212) with one or more payer financial institution systems 202, one or more customer-facing devices 208, and one or more external payment provider systems 210.

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

[0057] A payer financial institution may be a bank, savings and loan association, credit union, trust company, mortgage company, or similar financial institution. An external payment provider 210 may be, for example, a credit card company, online payment company, or similar financial institution.

[0058] The customer devices 208 may be operated by customers 206 who have financial accounts with the payer financial institution. The customer devices 208 may include, for example, smartphones, tablets, personal computers, and similar electronic devices. One or more networks 212 (e.g., wired or wireless networks, the Internet, or other networks) may interconnect and enable communication between elements of the financial system 200.

[0059] Overdraft allowance and courtesy pay handling

[0060] Related U.S. Patent No. 11,144,917 B1 provides a financial alert management and real-time remediation system (FAMS) that allows customers to remediate the above-mentioned NSF events in real time. However, financial institutions also generate other items that are not included in the exception handling process because they have been paid. These are referred to herein as "other presented items." For example, daily presented items include paid items, items and transactions that are NSF due to insufficient funds, and items and transactions that are paid if the financial institution offers overdraft allowance or courtesy pay services. According to an embodiment of the technology disclosed herein, an improved FAMS (hereinafter referred to as "FAMS") is provided that creates a complete view of all presented items (whether paid or not) for the customer and allows the customer full control over which items have been paid and which items (if any) they wish to return. As mentioned above, unlike typical NSF exceptions (those returned for insufficient funds), these items are not included in exception processing because they have been paid, and as a result, these "other presented items" are not separated out for review in exception processing operations. Therefore, the core processor does not generate reports of these "other presented items" for external partners.

[0061] One drawback of the current system is that paid items that have become overdrafted are not reported in a separate report or task that is easily visible to customers. Additionally, because these items are considered paid, there is no automated system in place to return them if requested by the customer. Therefore, making changes to paid items is currently a manual, time-consuming, and risky process. The risk is when a customer wants to return an item, but the due date for that item has passed. Such an item is considered a "late return" and may be rejected as an unacceptable late return, making the bank liable for the item.

[0062] Figure 3 is a flow chart illustrating a process 300 for a customer to manage overdraft authorization or courtesy pay items (collectively referred to herein as "authorized overdraft events") on their account at a financial institution, in accordance with some embodiments of the disclosed technology. For example, process 300 may be employed to manage NSF events on a customer's checking account where a check issued against the account exceeds the account's available balance when presented, but does not exceed the financial account's overdraft authorization. Process 300 is described with reference to Figures 2 and 3 and may be performed by FAMS 204 of Figure 2.

[0063] Elements of the disclosed processes are presented in a certain order. However, it should be understood that one or more elements of the processes may be performed in a different order, performed in parallel, or omitted entirely. Furthermore, the processes may include other elements beyond those presented. For example, the processes may include error handling functions in the event of an exception.

[0064] Referring to Figure 3, process 300 may include obtaining 302 an electronic file. The electronic file may include an overdraft authorization information data structure containing overdraft authorization information describing one or more overdraft authorization events and customers associated with the overdraft authorization events. The electronic file may include a contact information data structure containing an electronic address for each customer. The file may include rules specific to each instance / customer that differ from rules for another instance / customer.

[0065] This file contains information describing the events as well as customer information about the customers, which may include information such as the date and time the events occurred, a unique identifier code (UIC) that uniquely identifies each event, the account numbers of the customer accounts involved, the policy numbers of the negotiable instruments involved (e.g., check numbers), and the amounts of each negotiable instrument involved.

[0066] The customer information may include information such as customer name, customer number, customer contact information, etc. The customer contact information may include contact information such as email address, phone number, etc.

[0067] There may be various ways in which FAMS 204 electronically retrieves the electronic file from the payer financial institution 202. In some embodiments, FAMS 204 may poll the payer financial institution 202 to retrieve the electronic file. In other embodiments, the payer financial institution 202 may push the electronic file to FAMS 204. In some embodiments, FAMS 204 may retrieve the electronic file through an access process or application programming interface (API) provided by the payer financial institution 202. In some embodiments, FAMS 204 may retrieve the electronic file using robotic process automation that emulates the keystrokes of an employee at the payer financial institution 202. In some embodiments, a combination of these techniques may be used. In some embodiments, FAMS may request a specific process that allows access to underlying systems to retrieve the electronic file. These techniques may be performed in a highly encrypted security protocol environment.

[0068] This technical integration between FAMS and the payer financial institution to obtain electronic files is unprecedented and employs innovative technology to interface between the FAMS computer system and the payer financial institution's computer system. Traditionally, the process of receiving electronic files from FIs has been fully or partially manual. Performing this manual process wastes valuable time in a time-critical process. This automation and electronic nature makes the interaction between the payer FI and FAMS nearly instantaneous, freeing up payers' time to respond to events.

[0069] 3, process 300 may include, in response to obtaining the overdraft authorization information, automatically parsing the overdraft authorization information to obtain an overdraft authorization event for a customer associated with the overdraft authorization event 304. After the analysis, process 300 may include performing one or more operations for one or more customers.

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

[0071] For example, with further reference to Figure 2, after FAMS 204 obtains the overdraft authorization information, it may identify the customer 206 according to the customer information included in the overdraft authorization information and provide some or all of the overdraft authorization information to the customer device according to the contact information included in the customer information. For example, the notification may include information regarding the period during which the customer has the opportunity to correct the overdraft authorization event, including the end time and remaining time of the period. The notification message may include a message such as an email, a text message, a voicemail, a robocall, etc.

[0072] 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 running on the customer device 208 to open the SSO interface and may be authenticated by logging in to the SSO interface, for example, by providing a pre-configured user ID and password. In some embodiments, the authentication process may include multi-factor authentication.

[0073]

[0031] Referring again to Figure 3, process 300 may include providing 308 a user interface to a customer electronic device for display to the customer in response to the customer being authenticated at the financial institution's authentication interface. The user interface may display overdraft authorization information for each overdraft authorization event associated with the customer and display user-selectable elements, such as display elements of payment options. For example, referring again to Figure 2, FAMS 204 may provide the user interface to customer device 208.

[0074] FIG. 4 illustrates an example user interface 400 provided to a customer in accordance with some embodiments of the disclosed technology. Referring to FIG. 4, the user interface 400 may list 402 related negotiable instruments and, for each negotiable instrument, list information such as the check number, amount, etc. The user interface may also list one or more service fees charged by the financial institution for exception processing. The customer may use the user interface to select a fee for making a payment. The user interface may list a total payment amount. The customer need only select the total payment amount to make the payment.

[0075] User interface 400 may display a list of FI decisions for each negotiable instrument at 408. The FI decisions indicate the financial institution's decisions regarding the handling of the negotiable instrument. For example, the financial institution may determine whether the negotiable instrument should be paid for, paid as a courtesy payment, or returned. Interface 400 also allows the customer to override these decisions at 410. For example, the customer may decide to pay for the negotiable instrument, return the negotiable instrument to the payee, report the negotiable instrument as fraudulent, or stop payment on the negotiable instrument. Upon such customer selection, the FAMS may send an electronic message to the FI indicating the decision.

[0076] Referring again to FIG. 3 , process 300 may include generating and transmitting 310 a payment message in response to a customer selecting a payment option. The payment message may cause a payment for the negotiable instrument to be transferred, for example, to a financial account of the customer. The payment may be greater than the difference between the amount of the negotiable instrument and the balance in the financial account. For example, the payment may be the difference between the amount of the negotiable instrument and the balance in the financial account plus a service fee.

[0077] In some embodiments, the user interface may list multiple payment methods. For example, the payment methods may identify accounts that the customer has with an external payment provider 210. In such embodiments, the FAMS 204 (or a third party) may respond to the customer's selection of one or more payment methods by transferring the payment amount to the customer's financial account according to the selected payment method(s).

[0078] In some embodiments, the user interface may present options other than payment in response to the NSF. For example, the user interface may present an option for the customer to report fraud for the associated negotiable instrument. In such embodiments, FAMS 204 may report fraud for the negotiable instrument to the payer financial institution 202 in response to the customer selecting the option to report fraud.

[0079] In some embodiments, once the time period for remediating an NSF event has expired, the FAMS system may indicate in the user interface that the time period has expired and disable or remove the payment option in the user interface.

[0080] Pricing overdraft fees with the Pricing Model Grid

[0081] Financial institutions often charge customers a fee when a transaction is declined. For example, a financial institution may charge a customer an overdraft fee when a payment instrument is overdrawn. The payment instrument may be a debit card, check, ACH payment instrument, or similar payment instrument. The fee is typically a fixed amount regardless of the payment instrument value. For example, the fee may be set at $30. Many people would consider this fee too high if the payment instrument value was equal to or less than the fee amount. However, in current systems, the fee amount is a fixed amount regardless of the payment instrument value.

[0082] In some embodiments, the fee may vary depending on the amount of the associated transaction. For example, the fee may be determined by a pricing grid. An example pricing grid is shown in Table 1. Referring to Table 1, the pricing grid defines ranges for transaction amounts up to a predetermined exposure limit. For each range, the pricing grid defines an associated fee amount. For example, if the transaction amount is $25.00 or less, the pricing grid in Table 1 defines a fee of $5.00. For the highest range, the fee may be a default service fee. In some embodiments, the pricing grid may assign different fee codes to different ranges and different fees. Referring again to Table 1, in the above example, the fee code is 01. [Table 1]

[0083] 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 on their checking account when a check issued against the customer's account exceeds the account's available balance when presented, but does not exceed the account's overdraft limit. Process 500 is described with reference to FIGS. 2 and 5 and may be performed by FAMS 204 of FIG. 2.

[0084] 5, process 500 may include obtaining an electronic file 502. The electronic file and the method for obtaining the electronic file may be the same as that described with reference to FIG.

[0085] 5, process 500 may include, in response to obtaining the overdraft authorization information, automatically parsing the overdraft authorization information to obtain an overdraft authorization event for a customer associated with the overdraft authorization event 504. After the analysis, process 500 may include performing one or more operations for one or more customers.

[0086] For example, process 500 may include determining 506 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 assign the transaction amount to the grid to determine the fee. Alternatively, the FAMS may determine a fee code in a similar manner. The FAMS may provide the fee code to the FI or core processor.

[0087] In other embodiments, the fee may be stored in the FI rather than the FAMS. In these embodiments, the FAMS may determine a fee code based on the transaction amount and provide the fee code to the financial institution. Upon receiving the fee code, the FI may determine a fee based on the fee code and return the fee to the FAMS.

[0088] For example, process 500 may include generating and sending 508 an overdraft authorization notification message to the customer's electronic address. The overdraft authorization notification message and the method for sending the overdraft authorization notification message are described above with reference to Figure 3. The overdraft authorization notification message may include a link to an authentication interface of the institution associated with the customer. The link and authentication process may be the same as described with reference to Figure 3.

[0089]

[0023] Referring again to Figure 5, process 500 may include providing 510 a user interface on a customer electronic device for display to the customer in response to the customer being authenticated at the financial institution's authentication interface. The user interface may display overdraft authorization information for each overdraft authorization event associated with the customer and may display user selectable elements, such as display elements for payment options. For example, referring again to Figure 2, FAMS 204 may provide a user interface to customer device 208. The user interface may be similar to the user interface of Figure 4 described above.

[0090] 5, process 500 may include generating and sending a payment message in response to the customer selecting a payment option 512. Processing of the payment message may be the same as that described with reference to FIG.

[0091] Easy Select Processing

[0092] In the FAMS disclosed herein, customers are presented with a variety of trades and options. Many customers and small and medium-sized businesses do not have the time to analyze these trades and options in detail, but still want the opportunity to select the appropriate option for each trade. Factors that add to the complexity include time constraints, such as the small size of the device.

[0093] In some embodiments, the FAMS provides a "quick select" button as a display element in the user interface to enable easy-select processing of such items. Rather than making decisions for each transaction individually, customers may select a decision type and then select all transactions to which the selected decision type applies. This method is particularly efficient when there are a large number of transactions. This technique enables individuals and small business owners to make decisions in seconds instead of minutes. In some embodiments, the FAMS automatically groups transactions by decision type for quick decision review.

[0094] FIG. 6 illustrates an example of a first user interface 600 that may be provided to a customer to facilitate transaction selection in accordance with some embodiments of the disclosed technology. The user interface 600 may be provided as described above, or may be provided after the authentication and notification methods described above. Referring to FIG. 6 , the user interface 600 may list items at 602. The list may include account numbers, descriptions such as payee names, and item amounts. 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 to make a decision for each item in the list, as described above. The user interface 600 may further include a user-operable quick decision display element at 606. The customer may operate the display element 606 to select a decision type to apply to multiple items in the list, for example, to speed up the decision process.

[0095] FIG. 7 illustrates an example of a second user interface 700 that may be provided to a customer to facilitate an action selection in accordance with some embodiments of the disclosed technology. Referring to FIG. 7 , the customer interacts with the easy decision indicator 606 to select the decision type "Want to Pay." Other potential decision types may include deciding to pay the negotiable instrument, return the negotiable instrument to the payee, report the negotiable instrument as fraudulent, or stop payment on the negotiable instrument. After selecting a decision type, the customer can apply the decision type to a particular item by selecting that item. Referring to FIG. 7 , the selected item in 702 is marked with a "P." Once the customer makes a selection, the FAMS may send an electronic message to the FI indicating the decision, for example, as described above.

[0096] AI decision-making based on past behavior

[0097] Financial institutions have always had a hierarchy of presentment for processing debit and credit transactions. This process is rigid and involves assumptions about which customers (such as consumers or small businesses) want to pay for which transactions.

[0098] To date, financial institutions have had no knowledge or way to intelligently guess which transactions a customer may wish to pay or will default to a rigidly established sequence, resulting in frustration and problems for the customer as very important items due may be dishonored.

[0099] In some embodiments, the FAMS may select a customer's default decision for the customer's current transaction based on the customer's past behavior. For example, the FAMS may record and maintain which decisions a customer has previously selected for a particular transaction. The FAMS may also maintain a record of which payment method was used when the customer made and selected a payment.

[0100] In some embodiments, the FAMS uses algorithms to create a database of predictable behaviors to present to customers, making financial institution-defined sequences obsolete and allowing the default decisions selected to reflect the customer's past behavior, resulting in faster and more accurate decision making.

[0101] 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, the machine learning models and techniques may include decision trees, neural networks, gradient boosting, and the like. The machine learning model may be pre-trained on historical correspondences between decisions made and corresponding transaction parameters. This may be supervised, unsupervised, or a combination thereof, and may continue between operations for the life of the system. The model may continue to learn and improve over time. Parameters may include, but are not limited to, account number, payer identity, payee identity, item amount, item date, payment type (e.g., check, ACH, or debit card), and a final decision to process the item. A time frame and weight may be assigned to each data point and computations may be performed to determine behavioral patterns.

[0102] When a new item is presented, the parameters of the new item can be applied as inputs to the trained model. In response, the model may provide a default decision. The FAMS may present the item, the default decision, and one or more parameters to the user in a user interface. This process may occur after the authentication and notification procedures described above.

[0103] FIG. 8 illustrates an example user interface 800 that may be provided to a customer to enable an AI to make decisions based on past activity, in accordance with some embodiments of the disclosed technology. User interface 800 may be provided as described above, and may be provided after the authentication and notification methods described above. Referring to FIG. 8 , user interface 800 may list items at 802. The list may include account numbers, descriptions such as payee names, and amounts for the items. User interface 800 may include display elements 804 that list automated decisions for one or more items. Each display element 804 may include a drop-down menu to allow the customer to change the decisions. Once the customer makes a selection or confirms the automated decisions, the FAMS may send an electronic message to the FI indicating the decisions, e.g., as described above.

[0104] Analysis of spending limits

[0105] When customers are presented with multiple payment items and do not have enough funds to cover all of them, they may have difficulty understanding how much they can pay, what they need to pay, and how to pay. While budgeting models can be helpful, they do not provide immediate, concrete answers to these problems. Returning items can incur additional charges, increasing total costs and having a significant negative impact on the customer's credit rating, reputation, and future payment terms.

[0106] In some embodiments, the FAMS may provide a calculator tool that provides immediate and specific answers. For example, the tool may present the customer with multiple options for the amount the customer can afford to pay to correct some or all of the presented items. The calculations vary depending on the financial institution's proposal and the factors the financial institution wants to consider in the calculations. The tool is not a budgeting tool; rather, it is a calculator that helps the customer identify and utilize existing or available sources of funding. The tool may pose multiple questions and fill in the blanks to calculate the amount the customer can afford to pay.

[0107] 9 illustrates an example user interface 900 that may be provided to a customer for an "Amount Available to Pay" analysis, in accordance with some embodiments of the disclosed technology. User interface 900 may be provided as described above, and may be provided after the authentication and notification methods described above. User interface 900 may be presented when a user selects a user-operable "Amount Available to Pay" display element. This display element may be presented in a user interface listing items to be paid, including, for example, one or more of the user interfaces described above.

[0108] Referring to FIG. 9 , user interface 900 may list multiple funding sources at 902. For example, funding sources may include cash, credit cards, debit cards, transfers from accounts at other financial institutions, online payment systems, and microloan services. A customer may not be aware of the funding options available to them or how to access them. The system not only presents these options but also allows the customer to access them. A microloan application may be incorporated as an additional funding source if the customer does not have cash, other available funds, or available credit on a card. Once the customer adds a funding source, a dollar amount representing the total amount the customer can pay based on the funding sources and the customer's accounts at participating financial institutions may be displayed at 904.

[0109] A user-operable "Transaction Priority" indicator 906 allows the customer to change the presentation order selected by the financial institution. By allowing the customer to reprioritize or reorder transactions, the customer may end up paying the transactions they consider most important and returning other transactions that are less important. In some cases, additional funds may not be required.

[0110] Savings Analysis

[0111] Because of the potential for fees and downsides, it is useful to show customers how much they saved by taking a particular action. However, calculating these savings can be difficult, especially when presented with transactions that resulted in overdrafts. Furthermore, savings are estimated on a transaction-by-transaction basis and can vary depending on the type and timing of the transaction. The technology for making these estimates can be particularly difficult or even non-existent for non-sufficient funds (NSF) and overdraft (OD) transactions.

[0112] In some embodiments, the FAMS provides a savings estimator tool to estimate customer savings. FIG. 10 illustrates an example user interface 1000 provided to a customer by a savings estimator tool in accordance with some embodiments of the disclosed technology. User interface 1000 may be provided as described above, and may be provided after the authentication and notification methods described above. Referring to FIG. 10, user interface 1000 may list presented items and prompt the customer to answer specific questions for each item. The savings estimator tool features a novel processing backend that estimates savings based on the customer's responses.

[0113] In one example, the tool may determine the recipient of each item, for example, by processing an image of the item. Based on the recipient, the tool may ask for the purpose of the item (e.g., rent payment, mortgage payment, credit card payment, car payment, etc.). The tool may estimate savings based on the purpose. The estimated savings may include priority return fees, late fees, restocking fees, insurance reactivation fees, collection fees, phone reactivation fees, and similar fees.

[0114] Many retail receipts include sales discounts based on the original price. When such transactions are presented as NSF / OD items, it is difficult to determine the savings. Currently, such savings estimates are based on industry standards and most likely costs. However, the savings estimator tool disclosed herein asks the customer questions to make this determination.

[0115] Similarly, the tool may take into account late fees or restocking fees for returned items. Currently, such fees are estimated as a percentage of the amount paid. The savings estimator tool of the present disclosure asks questions of the customer to make this determination.

[0116] The tool may take into account the type of transaction when estimating savings. For example, the tool may assume an industry standard restocking fee, such as $25.00, for returned items.

[0117] FIG. 11 illustrates an example user interface 1100 that may be provided to a customer for savings analysis in accordance with some embodiments of the disclosed technology. User interface 1100 may be provided as described above, and may be provided after the authentication and notification methods described above. User interface 1100 may be presented when a user selects a user-operable "Savings" display element. The "Savings" display element may be presented in a user interface that lists upcoming payment items, including, for example, one or more of the user interfaces described above. Referring to FIG. 11, user interface 1100 may summarize and present estimated savings based on decisions selected by the user on user interface 1000 of FIG. 10.

[0118] Real-time bank check fraud prevention tool

[0119] A cashier's check is a prepaid bank check purchased and used by customers, typically for large transactions such as loan settlements or the purchase of high-value goods. Banks and merchants trust that cashier's checks are secure because the customer has paid in advance. However, cashier's checks can sometimes be used fraudulently. Currently, there is no way to determine whether a cashier's check is fraudulent. Banks and merchants generally accept cashier's checks with the confidence that they are not fraudulent. However, currently, there is no technological solution to "verify" or "guarantee" that a cashier's check is valid until it clears the bank.

[0120] In some embodiments, the FAMS may provide a real-time bank check fraud prevention tool that leverages financial institution data to verify the authenticity of bank checks before they are accepted. This technology has the unique advantage of being a central hub that validates certain criteria when bank checks are scanned or entered into the FAM. Parameters used by the FAMS to verify bank checks include date, routing number, account number, check number, amount, and payee. The FAMS may connect via secure data lines to various systems, including core systems, positive pay systems, accounting systems, and other systems where cashier check data is maintained, to verify the check data.

[0121] 12 is a flow chart illustrating a real-time bank check fraud prevention tool process 1200 in accordance with some embodiments of the disclosed technology. The process 1200 is described with reference to FIGS. 2 and 12 and may be performed by the FAMS 204 of FIG. 2.

[0122] Referring to FIG. 12 , process 1200 may include obtaining 1202 an electronic file. The electronic file may include a bank check data structure that includes bank check information for one or more bank checks presented at the first financial institution. For example, the tool may provide a user interface on an electronic device at the financial institution. The user interface may include display elements that allow a user at the financial institution to enter bank check information for one or more bank checks presented at the first financial institution. In some embodiments, the user may enter the information manually, and the entered information is included in the file. In some embodiments, the user may simply scan the checks, and an image of the check is included in the file. The electronic file and the method for obtaining the electronic file may be the same as that described with reference to FIG. 3 .

[0123] 12, process 1200 may include, upon obtaining the bank check information, automatically parsing the bank check information to obtain one or more bank check events according to a routing number included in the bank check information 1204. After the parsing, process 1200 may include performing one or more operations for one or more customers.

[0124] This process may include identifying the second financial institution based on the routing number. For example, the second institution may be a bank check issuer or payer, a core processor, or similar. This process may include determining whether the second institution supports fraud prevention tools. If not, the tools may send a message to the first financial institution indicating that the second financial institution is not a participating financial institution.

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

[0126] The process 1200 may include receiving 1208 an electronic verification response message in response to the electronic verification request message. The process 1200 may include determining 1210 whether the bank check was validated based on the electronic verification response message.

[0127] The process 1200 may include sending an electronic response message to the financial institution. The electronic response message may indicate whether the bank check was validated 1212. For example, the tool may provide a user interface on an electronic device of the financial institution. The user interface may include a display element that indicates whether the bank check was validated based on the electronic response message.

[0128] Real-time fraud reporting tool

[0129] Fraudulent items may be presented against a customer's account and requested for payment. A common example is check fraud. Currently, for several reasons, it is not possible for customers to detect and report fraudulent items in real time, or even in a timely manner. Depending on the processing method, the item may not be posted to the customer's account until the 24-hour return acceptance window has expired. As a result, by the time the customer identifies the item, it is too late for the 24-hour return window. Even if the processing system posts the item to the customer's account within 24 hours, the customer often does not receive a notification that allows them to identify the item in time. And even if the customer sets up such a notification, the customer must still identify the item, determine whether it is fraudulent, manually notify the financial institution, complete the necessary paperwork, and manually return the item—all within 24 hours.

[0130] As a result, customers may not learn of the existence of a fraudulent item until days later. They then must deal with the negative impact of an unexpected item being paid for from their available balance. Furthermore, other items may be returned because, for example, the customer does not have sufficient funds in their account to pay for the item. These returns can strain the relationship between the customer and the merchant and may result in additional charges being assessed to the customer by third parties, such as returned check fees, late fees, restocking fees, and worsening future payment terms.

[0131] Financial institutions may also be adversely affected. Because they were unaware of the fraud until it was too late, the financial institution may have to reimburse the customer and pay other items that are found to be fraudulent. For example, the customer's financial institution (i.e., the recipient financial institution) may have accepted the fraudulent item for deposit and may not know that the item is being returned. This results in a loss for the recipient financial institution. If an item is returned because it was fraudulent, the recipient bank must bill the customer who deposited the item. If the customer does not have sufficient funds to pay for the returned item, they will be overdrawn until and unless they can repay the fraudulent funds already used.

[0132] In some embodiments, FAMS offers a real-time fraudulent item reporting tool. Using this tool, customers can indicate that a presented item will cause an overdraft, is fraudulent, and can be returned within the 24-hour return period. This tool not only notifies customers of the specific item causing the overdraft, but also provides the option to "report fraud" directly within the user experience. The item is immediately flagged for return, and the financial institution does not have to take any action other than documenting the customer's report of fraud or misconduct. This tool allows customers to stop problems before they occur, and it also prevents payer financial institutions from incurring losses due to fraud caused by late returns.

[0133] Additionally, FAMS will immediately notify the recipient financial institution that an item is being returned if the recipient bank supports this tool. This notification process typically takes a minimum of 24 hours and is only implemented for items over a certain value. There is currently no 24-hour notification requirement for smaller items. FAMS notification allows the recipient financial institution to take prompt action to protect the funds in the recipient's account so that fees can be paid, if necessary, and to prevent further losses.

[0134] 13 is a flow chart illustrating a process 1300 for a real-time fraud item reporting tool in accordance with some embodiments of the disclosed technology. The process 1300 is described with reference to FIGS. 2 and 13 and may be performed by the FAMS 204 of FIG. 2.

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

[0136] Upon obtaining the exception information, the process 1300 may include automatically analyzing the exception information with a computer processor to obtain events associated with customers 1304. After the analysis, the process 1000 may include performing one or more actions for one or more customers.

[0137] The process 1300 may include the computer processor generating and sending 1306 an event notification message to the customer's electronic address, the event notification message including a link to an authentication interface of the payer financial institution.

[0138] 3 , process 1300 may include, in response to the customer being authenticated at the authentication interface, the computer processor providing 1308 a user interface to the customer electronic device for display to the customer. The user interface may display information about each event associated with the customer and user-selectable display elements, such as a display element for reporting fraud with respect to each negotiable instrument.

[0139] The process 1300 may include, upon the customer selecting the display element to report fraud, generating and transmitting 1310 a first fraud report message to the payor financial institution and a second fraud report message to the payee financial institution. The first and second fraud report messages may identify corresponding negotiable instruments.

[0140] FIG. 14 illustrates an example user interface 1400 that may be provided to a customer by a real-time fraudulent item reporting tool, consistent with some embodiments of the disclosed technology. User interface 1400 may be provided as described above, or may be provided after the authentication and notification methods described above. Referring to FIG. 14 , user interface 1400 may list items at 1402. The list may include account numbers, descriptions such as payee names, and item amounts. User interface 1400 may include display elements 1404 that list the FI's decisions about the items. User interface 1400 may include user-operable display elements 1406 that also list the FI's decisions about the items. Each display element 1406 may provide options, such as drop-down menus or other user-operable display elements that allow the customer to change their decisions. In the example of FIG. 14 , the customer manipulated the drop-down menu of the top item in the list at 1408 to indicate that the item is fraudulent.

[0141] Real-time debit card automated opt-in process

[0142] When a customer pays with a debit card, if 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 allowance service. If the customer opts in, the debit card transaction is paid with the overdraft facility. However, many customers do not opt ​​in due to fear of being charged overdraft fees. Also, because paying with a debit card is so convenient, customers often do not carry checks or cash as alternative payment methods. When a debit card payment is declined, the customer has no other means of payment. This can be a significant problem for customers, for example, by making payments at the grocery store or gas station. Furthermore, the debit card authorization process is so fast (in nanoseconds) that there is no time to find an alternative way to complete the transaction or to inform the customer of the option to change the debit card's "opt-out" status.

[0143] In some embodiments, the FAMS provides a real-time automated debit card opt-in process. In these embodiments, the FAMS gives the FI the option to turn this service "on." The technology is built into the card system and raises a flag when a debit card transaction is declined. This flag is sent to the FAMS, which in turn sends a message to the customer informing them that the transaction was declined due to the card's "opt-out" status. The message may be sent via SMS, email, or a similar service. A customer who wishes to "opt-in" may send a response to this message, which is received by the FAMS. Upon receiving the message, the FAMS sends a maintenance to the Reg E "Opt-In" field to the back-end system. Once the field is updated in the back-end system, the customer may retry the transaction to complete the authorization.

[0144] 15 is a flowchart illustrating a debit card automatic opt-in process 1500 in accordance with some embodiments of the disclosed technology. However, while the disclosed technology is described with respect to debit cards, it is readily applicable to accounts with similar "opt-in" capabilities.

[0145] Referring to Figure 15, a customer uses a debit card to pay a point of sale (POS) transaction at 1502. If the debit card account has sufficient available funds at 1504, the transaction is posted to the core system or memo system and completed successfully at 1506. However, if the debit card account does not have sufficient available funds at 1504, a determination is made as to whether the customer has subscribed to overdraft protection services at 1508. If the customer has opted in to overdraft protection services, the transaction may be posted to the core system or memo system and completed successfully at 1506.

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

[0147] ACH Warehouse Analytics for Payments

[0148] ACH (Automated Clearing House) systems utilize a warehouse, referred to herein as the "ACH warehouse," to store receivables and payables until the date they are posted. Financial institutions use the ACH warehouse to store ACH entries but do not provide customers with any information about what is scheduled to be posted next. Because this service is not integrated into the financial institution's processes, customers are unaware of impending ACH transactions.

[0149] In some embodiments, FAMS provides ACH warehouse analytics. FAMS may connect to a financial institution's ACH warehouse and detect transactions that are pending posting within 24 hours of their due date. FAMS provides this important information to customers in a user interface, allowing them to take action such as overdrafting and paying the items within 24 hours. If a customer has receivables in the ACH warehouse that will post within 24 hours, FAMS can display this information in the user interface and notify the customer of the upcoming payment deadline. This information is useful to customers when selecting items to pay and choosing a payment method.

[0150] FIG. 16 is a flowchart illustrating a process 1500 for providing an ACH warehouse analysis, in accordance with some embodiments of the disclosed technology. Referring to FIG. 16, a customer may request 1602 an ACH warehouse analysis using a user interface of a FAMS. FIG. 17 illustrates an example user interface 1700 through which a customer may request an ACH warehouse analysis, in accordance with some embodiments of the disclosed technology. User interface 1700 may be provided as described above and may be provided after the authentication and notification methods described above. Referring to FIG. 17, user interface 1700 may present multiple scenarios for the customer to choose from. The example of FIG. 17 includes a scenario in which the customer does not have any extra funds, a scenario in which the customer can pay for the items, and a scenario in which the customer has an alternative source of funds.

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

[0152] 18 illustrates an example user interface 1800 that may be provided to a customer by a real-time fraud item reporting tool, in accordance with some embodiments of the disclosed technology. User interface 1800 may be provided as described above and may be provided after the authentication and notification methods described above. Referring to FIG. 18, user interface 1800 may list detailed information regarding upcoming and ongoing transactions.

[0153] Automatic GL Reconciliation

[0154] When transactions occur outside the core processor, automation is difficult to achieve given the level of access required as well as the correct sequence of transactions to customer accounts and general ledgers (GLs). This problem is exacerbated as financial institutions do not allow other external vendors to update customer accounts or GLs. These processes are not provided by external vendors due to limited and prohibited access.

[0155] In some embodiments, the FAMS provides automated GL reconciliation services. FAMS technology is integrated with a financial institution's core processor. FAMS also adheres to many of the financial audit and security requirements that financial institutions are subject to. To this end, the FAMS may initiate certain processes within the core processor. Examples include processes for updating customer transactions, various GL transactions, and return codes based on customer changes made throughout the day. Processes may also vary across the processing hierarchy.

[0156] One such transaction is the customer transaction process. When a customer selects "Pay with cash" or "Pay with available balance," a hold must be placed on the customer's account to reserve the funds. This prevents the funds from being used for other purposes, such as debit card transactions. When a customer selects "Pay with credit card," the amount authorized by the merchant is not deposited into the customer's account, but into the merchant's clearing account. Again, the purpose is to reserve the funds until the item is paid for.

[0157] Other processes include GL transactions. GL transactions include fees, merchant services, and interchange. Each transaction triggers a specific GL process. These GL processes are finalized by the financial institution, but FAMS processes them to reflect miscellaneous activities after the deadline for action has passed. These GL entries create an automated settlement process for financial institutions by moving funds to the appropriate GL and customer accounts, eliminating the need to manually process transactions.

[0158] Another process is updating the return code. This process is an important part of the "end of day" process. The default decisions made based on the financial institution's hierarchical propagation process must be updated based on the customer's decisions during the available timeframe. This process performs one of several actions for each item, such as removing the item from the "return file" and paying it, adding the item to the "return file" for return, or, if the return reason is not NSF (insufficient funds), changing the return code to reflect the true reason for return (e.g., stop payment for fraud). Other pre-defined return codes can also be used.

[0159] FIG. 19 is a flowchart illustrating a process 1900 for providing automatic GL reconciliation in accordance with some embodiments of the technology disclosed herein. FIG. 19 shows the process flow proceeding from left to right. The system updates the FAMS database when a customer selects to pay, return, or report fraud at 1902, and queues the transaction for reflection after the "action deadline" at 1904. At this point, the transaction is initiated based on the customer's decision. For example, all fees are collected, and the transaction is authorized in the merchant account. At this point, any account holds placed to secure funds designated for these transactions are released, and payment is made for the items through the account. In addition to this processing, return, payment, fraud, and stop payment codes are updated in the return file to match the processed transaction. The final GL reflects the corresponding transaction amounts, such as service charges, convenience fees, and merchant settlements (for card transactions). The FI's return file is updated at 1906 to reflect customer changes, such as the removal of paid items, fraudulent items, and stop payments. All other items in the return file remain unchanged.

[0160] FAMS management automation (AFA)

[0161] In some embodiments, the FAMS provides an automated FAMS administration (AFA) tool that allows multiple financial institutions to be onboarded into the FAMS at once and provides a mechanism for each financial institution to configure some of its key data, such as fee structures, settings, messaging, etc. The AFA tool is a process that separates financial institution data based specifically on each financial institution's technical specifications from each financial institution's business decisions.

[0162] The financial institution portion may be primarily exposed to financial institutions based on administrator roles for access to the AFA tool. Once submitted, this information may be automatically uploaded to the designated FAMS "tenant" (e.g., financial institution). Certain configurable data points may be exposed for maintenance by qualified financial institution employees.

[0163] Data points for each financial institution include service fee, convenience fee (dollars / %), business rules based on various criteria, messaging, branding (color / logo), return item code, NSF / OF fee refund matrix, settlement general ledger, time zone, website, primary phone number, group fraudulent email, courtesy pay program name, contact name, customer portal opening hours, closing hours, mission control portal opening hours, closing hours, service fee discount, holiday schedule, business day schedule, billing address, billing contact, and more.

[0164] Data points for the technical team include: Member Portal; URL, Okta Client ID - Mission Control; URL, Okta Client OD, Group ID - Credit Union; Core API, Transaction API, Database Connection String and Database Name - Sendgrid; API Key, Email, URL, Name - Twilio; SID Token, Phone - Payment Details; Secret Key, Access Key, Public Profile - ServiceBusEndpoint - Azure Storage Account Details - Storage Account Endpoint, Blob Path from which ETL is triggered - SFTP Details - Host, Port, Username, Password, Path - Decision Code - ACH Payment, Fraud, Draft, Payment, Fraudulent, etc.

[0165] An AFA tool role may include a role name and a role description. Settings may include financial information, convenience fee threshold, transaction fee threshold, FAMS fee threshold, admin email, and IDP settings.

[0166] The AFA tool also has sections that display the dashboard, company settings, users, tenants, and configuration. Other data fields may be added as the requirements of the financial institution change, including specific messaging for general technology, processing codes (such as GL codes, return codes, and similar codes), discounts, business rule criteria, and analytics.

[0167] Customer Settings

[0168] Financial institutions currently offer customer preferences that do not allow customers to configure interfaces and processes for more convenient and everyday use, and do not provide sufficient flexibility to create preferences that fit their financial and everyday needs. Without these preferences, customers cannot configure alerts, payment preferences, automated decisions, or other processes that would simplify and enhance the technology's usability.

[0169] In some embodiments, the FAMS exposes these customer preferences to the customer. The preferences may be unique to each customer and may establish specific processes for automating assistance to the customer. These preferences may be customer-defined and stored by the customer until updated. Examples of preferences include alert timing, secondary alerts, preferred payment methods, automated decisions regarding certain types of payments, amount alerts, suspicious payee alerts, overdraft tolerance alerts, preferred notification methods, contact information updates, lifeline template settings, and account nicknames. Because the FAMS operates "behind the vault door" (after customer authentication has occurred), these preferences are considered secure based on the financial institution's pre-approved authentication process and can be updated to core systems used by the financial institution.

[0170] Job notification

[0171] There are many job search sites available and they are easily accessible. However, financial institutions have not included job information in their offers, even though this would be a significant benefit to consumers, especially those facing financial difficulties. Continuous job information notifications would be convenient and useful for people facing financial difficulties.

[0172] In some embodiments, FAMS provides these job postings. By providing job postings through a convenient, well-known portal where customers conduct their banking needs today, FAMS provides customers with a "one-stop" financial service for all their financial needs. Online banking is a primary financial institution tool used by consumers and small businesses. The Job Postings tab is located within the Online Banking tab, allowing consumers to conveniently view local job postings while using online banking.

[0173] FAMS may use algorithms and rules to determine available jobs based on criteria related to a customer's checking account activity and overdraft / NSF item responses. These criteria may include past job titles and employers, work location, and minimum working age. FAMS may also aggregate job postings from various sites to present jobs that may match the consumer's work history in one location. These data points, along with a weighted score, may be used to calculate the best job for each customer. FAMS may allow customers to broaden their search by providing additional information. In some embodiments, this additional information is not retained by FAMS.

[0174] 20 is a block diagram illustrating an example of a computer system 2000 in which embodiments described herein may be implemented. The computer system 2000 includes a bus 2002 or other communication mechanism for communicating information, and one or more hardware processors 2004 coupled with the bus 2002 for processing information. The hardware processors 2004 may be, for example, one or more general-purpose microprocessors.

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

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

[0177] The computer system 2000 may be coupled via a bus 2002 to a display 2012, such as a liquid crystal display (LCD) (or touch screen) 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. Other types of user input devices include a cursor control device 2016, such as a mouse, trackball, or cursor direction keys, which are used to communicate directional information and command selections to the processor 2004 to control cursor movement on the display 2012. In some embodiments, cursor control as well as directional information and command selections may be implemented by receiving touches on a touch screen without the use of a cursor.

[0178] The computing system 2000 may include user interface components for implementing a GUI that may be stored on a mass storage device as executable software code for execution by a computing device, and examples of such components may include software components, object-oriented software components, class components, task components, or other components, processes, functions, attributes, procedures, subroutines, program code segments, drivers, firmware, microcode, circuits, data, databases, data structures, tables, arrays, variables, and the like.

[0179] In general, terms such as “component,” “engine,” “system,” “database,” and “data store,” as used herein, may refer to logic embodied in hardware or firmware, or to software instructions written in a programming language such as Java, C, or C++, possibly with entry and exit points. Software components may be compiled and linked into an executable program, installed in a dynamic link library, or written in an interpreted programming language such as BASIC, Perl, or Python. It is understood that software components may be callable by other components, by themselves, and / or in response to detected events or interrupts. Software components configured to run on a computing device may be provided on a computer-readable medium such as a compact disc, digital video disc, flash drive, magnetic disk, or other tangible medium, or as a digital download (or may originally be stored in a compressed or installable format that requires installation, decompression, or decryption before execution). Such software code may be stored in part or in whole in a memory device of the executing computing device for execution by the computing device. The software instructions may be embedded in firmware such as an EPROM. It should also be understood that the hardware components may consist of multiple interconnected logic units, such as gates and flip-flops, and / or may consist of programmable units, such as programmable gate arrays or processors.

[0180] The computer system 2000 may use customized hardwired logic, one or more ASICs or FPGAs, firmware, and / or program logic to implement the techniques described herein. In combination with a computer system, the computer system 2000 functions or is programmed as a special-purpose machine. According to one embodiment, the techniques described herein are performed by the computer system 2000 through execution by the processor 2004 of one or more sequences of one or more instructions stored in the main memory 2006. Such instructions may be loaded into the main memory 2006 from another storage medium, such as the storage device 2010. Execution of the sequences of instructions stored in the main memory 2006 causes the processor 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.

[0181] As used herein, terms like "non-transitory media" refer to any medium that stores data and / or instructions that cause a machine to operate in a specific 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, magnetic data storage media, such as floppy disks, flexible disks, hard disks, solid-state drives, and magnetic tape; optical data storage media, such as CD-ROMs; physical media with holes in any pattern; memory chips or cartridges, such as RAM, PROM, EPROM, FLASH-EPROM, and NVRAM; and networks thereof.

[0182] Non-transitory media are distinct from, but may be used in conjunction with, transmission media. Transmission media is a medium used to transfer information between non-transitory media. For example, transmission media include coaxial cables, copper wire, and fiber optics, including the wires that comprise bus 2002. Transmission media may also be provided as acoustic or light waves, such as those generated by radio wave and infrared data communications.

[0183] Computer system 2000 also includes a communication interface 2018 coupled to bus 2002. Network interface 2018 provides a two-way data communication connection to one or more network links that are connected to one or more local networks. For example, communication interface 2018 may be an Integrated Services Digital Network (ISDN) card, a cable modem, a satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, network interface 2018 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN (or a WAN component for communicating with a WAN). Wireless links may also be implemented. In any such embodiment, network interface 2018 sends and receives electrical, electromagnetic, or optical signals that carry digital data streams representing various types of information.

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

[0185] The computer system 2000 can send messages and receive data, including program code, through the network(s), network link, and communication interface 2018. In the Internet example, a server may send a requested code for an application program through the Internet, an ISP, a local network, and communication interface 2018.

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

[0187] Each of the processes, methods, and algorithms described above may be embodied in code components executed by one or more computer systems or computer processors comprising computer hardware, and may be fully or partially automated. One or more computer systems or computer processors may also operate to support the execution of related tasks in a "cloud computing" environment or as "software as a service" (SaaS). The processes and algorithms may be implemented in part or in whole in application-specific circuitry. The various features and processes described above may be used independently or in various combinations. Different combinations and subcombinations are intended to be within the scope of the present disclosure, and certain method or process blocks may be omitted in some examples. Furthermore, the methods and processes described herein are not limited to a particular order, and associated blocks or states may be executed in a different order, in parallel, or otherwise. Blocks or states may be added or removed from the disclosed example embodiments. Certain operations or processes may be distributed across multiple computer systems or computer processors, and may be split across multiple machines, as well as across a single machine.

[0188] As used herein, a circuit may be implemented in any form of hardware or a combination of hardware and software. For example, one or more processors, controllers, ASICs, PLAs, PALs, CPLDs, FPGAs, logic components, software routines, or other mechanisms may be implemented to form a circuit. With respect to implementation, various circuits described herein may be implemented as discrete circuits, or the described functions and features may be shared in part or in whole by one or more circuits. Although various functions or elements may be described or claimed as separate circuits, these functions and elements may be shared by one or more common circuits. As such, such description does not require or imply that separate circuits are necessary to implement each function or element. When all or a portion of a circuit is implemented using software, such software may be implemented to operate on a computing or processing system, such as computer system 2000, that is capable of performing the functions described with respect thereto.

[0189] As used herein, the term "or" can be interpreted in either an inclusive or exclusive sense. Furthermore, a description of a resource, process, or structure in the singular should not be interpreted as excluding a plurality. In particular, conditional expressions such as "can," "could," "might," or "may" generally mean that certain embodiments include certain features, elements, and / or steps, but not other embodiments, unless otherwise specified or understood from the context in which they are used.

[0190] Terms and phrases used herein, and variations thereof, unless expressly stated otherwise, are to be considered open ended and not limiting. Adjectives such as "conventional," "traditional," "usual," "standard," "known," and similar terms should not be construed as limiting the described items to a given period of time or to items available at a given time, but instead should be construed as embracing conventional, traditional, ordinary, or standard technology that may be available or known at any time now or in the future. The use of broadening words and phrases, such as "one or more," "at least," "including but not limited to," and the like, should not be construed to imply that narrowing is intended or required when such broadening phrases are not used.

Claims

1. 1. A system for providing alert management and real-time remediation, the system comprising: one or more hardware processors; a non-transitory machine-readable storage medium encoded with instructions executable by the one or more hardware processors to perform a plurality of processes; The plurality of processes include: receiving, by the one or more hardware processors, an electronic file including an overdraft authorization information data structure including overdraft authorization information representing one or more overdraft authorization events and customers associated with the overdraft authorization events, and a contact information data structure including an electronic address for each customer; In response to receiving the overdraft authorization information, automatically analyzing, by the one or more hardware processors, the overdraft authorization information to obtain an overdraft authorization event for the customer associated with the overdraft authorization event; For one or more of said customers, determining, by the one or more hardware processors, for each overdraft authorization event associated with the customer, a time period during which the customer has the opportunity to cure the overdraft authorization event; generating and transmitting, by the one or more hardware processors, an overdraft authorization notification message to the customer's electronic address, the overdraft authorization notification message including a link to an authentication interface of an institution associated with the customer; receiving, by the one or more hardware processors, communications transmitted by the authentication interface; determining, by the one or more hardware processors, whether the customer has been successfully authenticated by the authentication interface based on the communication sent by the authentication interface; and in response to determining that the customer has been successfully authenticated via the authentication interface, providing, by the one or more hardware processors, a user interface on a customer electronic device for display to the customer, the user interface displaying overdraft authorization information for each overdraft authorization event associated with the customer and user-selectable display elements including a display element for payment options, the overdraft authorization information for each overdraft authorization event including an indication of a period of time within which the customer has the opportunity to cure the overdraft authorization event; determining, by the one or more hardware processors, whether a time period for a first overdraft authorization event has expired; in response to determining that the time period for the first overdraft authorization event has expired, causing the one or more hardware processors to display an indication to the customer in the user interface that the time period has expired, and causing the one or more hardware processors to remove from the user interface a display element of a payment option for the first overdraft authorization event; creating and transmitting, by the one or more hardware processors, a payment message in response to determining that the customer has selected the payment option for the first overdraft authorization event before the time period for the first overdraft authorization event expires, the payment message resulting in a payment to the institution; Including, the system.

2. each overdraft authorization event represents an overdraft authorization event in a financial account of a customer of the institution, the overdraft authorization information identifying paid negotiable instruments drawn on the financial account, the amount of the paid negotiable instruments exceeding the available monetary balance of the financial account but not exceeding the overdraft allowance of the financial account; The system of claim 1 .

3. The plurality of processes further comprises: Identifying, by the one or more hardware processors, at the user interface, the negotiable instrument whose service fee and payment amount correspond to the difference between the excess of the amount of the negotiable instrument over the available monetary balance of the financial account; providing, via the one or more hardware processors, a plurality of remediation options in the user interface, including an option to pay the payment amount; The system of claim 2 , comprising:

4. The plurality of processes further comprises: displaying, by the one or more hardware processors, a plurality of payment methods in response to the displayed negotiable instrument and the customer's selection of the payment option; In response to the customer selecting one of the plurality of payment methods, initiating, by the one or more hardware processors, a payment to the financial account according to the selected payment method; The system of claim 3 , comprising:

7. The plurality of processes further comprises: processing, by the one or more hardware processors, one or more rules to determine at least one of the service fee and the duration; The system of claim 1 , comprising:

8. a non-transitory machine-readable storage medium encoding instructions executable by one or more hardware processors of a computing component to provide alert management and real-time remediation; receiving, by the one or more hardware processors, an electronic file including an overdraft authorization information data structure including overdraft authorization information representing one or more overdraft authorization events and customers associated with the overdraft authorization events, and a contact information data structure including an electronic address for each customer; In response to receiving the overdraft authorization information, automatically analyzing, by the one or more hardware processors, the overdraft authorization information to obtain an overdraft authorization event for the customer associated with the overdraft authorization event; For one or more of said customers, determining, by the one or more hardware processors, for each overdraft authorization event associated with the customer, a time period during which the customer has the opportunity to cure the overdraft authorization event; generating and transmitting, by the one or more hardware processors, an overdraft authorization notification message to the customer's electronic address, the overdraft authorization notification message including a link to an authentication interface of an institution associated with the customer; receiving, by the one or more hardware processors, communications transmitted by the authentication interface; determining, by the one or more hardware processors, whether the customer has been successfully authenticated by the authentication interface based on the communication sent by the authentication interface; and in response to determining that the customer has been successfully authenticated via the authentication interface, providing, by the one or more hardware processors, a user interface on a customer electronic device for display to the customer, the user interface displaying overdraft authorization information for each overdraft authorization event associated with the customer and user-selectable display elements including a display element for payment options, the overdraft authorization information for each overdraft authorization event including an indication of a period of time within which the customer has the opportunity to cure the overdraft authorization event; determining, by the one or more hardware processors, whether a time period for a first overdraft authorization event has expired; in response to determining that the time period for the first overdraft authorization event has expired, causing the one or more hardware processors to display an indication to the customer in the user interface that the time period has expired, and causing the one or more hardware processors to remove from the user interface a display element of a payment option for the first overdraft authorization event; creating and transmitting, by the one or more hardware processors, a payment message in response to determining that the customer has selected the payment option for the first overdraft authorization event before the time period for the first overdraft authorization event expires, the payment message resulting in a payment to the institution; A non-transitory machine-readable storage medium comprising instructions for causing the one or more hardware processors to perform a plurality of processes, including:

9. each overdraft authorization event represents an overdraft authorization event in a financial account of a customer of the institution, the overdraft authorization information identifying paid negotiable instruments drawn on the financial account, the amount of the paid negotiable instruments exceeding the available monetary balance of the financial account but not exceeding the overdraft allowance of the financial account; The non-transitory machine-readable storage medium of claim 8.

10. The plurality of processes further comprises: Identifying, by the one or more hardware processors, at the user interface, the negotiable instrument whose service fee and payment amount correspond to the difference between the excess of the amount of the negotiable instrument over the available monetary balance of the financial account; providing, via the one or more hardware processors, a plurality of remediation options in the user interface, including an option to pay the payment amount; 10. The non-transitory machine-readable storage medium of claim 9, comprising:

11. The plurality of processes further comprises: displaying, by the one or more hardware processors, a plurality of payment methods in response to the displayed negotiable instrument and the customer's selection of the payment option; In response to the customer selecting one of the plurality of payment methods, initiating, by the one or more hardware processors, a payment to the financial account according to the selected payment method; 11. The non-transitory machine-readable storage medium of claim 10, comprising:

14. The plurality of processes further comprises: processing, by the one or more hardware processors, one or more rules to determine at least one of the service fee and the duration; 9. The non-transitory machine-readable storage medium of claim 8, comprising:

15. 1. A method for providing alert management and real-time remediation via one or more hardware processors programmed with computer-executable instructions, comprising: receiving, by the computer processor, an electronic file including: an overdraft authorization information data structure including overdraft authorization information representing one or more overdraft authorization events and customers associated with the overdraft authorization events; and a contact information data structure including an electronic address for each customer; In response to receiving the overdraft authorization information, automatically analyzing, by the computer processor, the overdraft authorization information to obtain an overdraft authorization event for the customer associated with the overdraft authorization event; For one or more of said customers, determining, by the one or more hardware processors, for each overdraft authorization event associated with the customer, a time period during which the customer has the opportunity to cure the overdraft authorization event; generating and transmitting, by the computer processor, an overdraft authorization notification message to the customer's electronic address, the overdraft authorization notification message including a link to an authentication interface of an institution associated with the customer; receiving, by the one or more hardware processors, communications transmitted by the authentication interface; determining, by the one or more hardware processors, whether the customer has been successfully authenticated by the authentication interface based on the communication sent by the authentication interface; and in response to determining that the customer has been successfully authenticated via the authentication interface, providing, by the one or more hardware processors, a user interface on a customer electronic device for display to the customer, the user interface displaying overdraft authorization information for each overdraft authorization event associated with the customer and user-selectable display elements including a display element for payment options, the overdraft authorization information for each overdraft authorization event including an indication of a period of time within which the customer has the opportunity to cure the overdraft authorization event; determining, by the one or more hardware processors, whether a time period for a first overdraft authorization event has expired; in response to determining that the time period for the first overdraft authorization event has expired, causing the one or more hardware processors to display an indication to the customer in the user interface that the time period has expired, and causing the one or more hardware processors to remove from the user interface a display element of a payment option for the first overdraft authorization event; creating and transmitting, by the one or more hardware processors, a payment message in response to determining that the customer has selected the payment option for the first overdraft authorization event before the time period for the first overdraft authorization event expires, the payment message resulting in a payment to the institution; A method for providing the above.

16. 16. The method of claim 15, wherein each overdraft authorization event represents an overdraft authorization event in a financial account of a customer of the institution, the overdraft authorization information identifies paid negotiable instruments drawn on the financial account, and the amount of the paid negotiable instruments exceeds the available monetary balance of the financial account but does not exceed the overdraft allowance of the financial account.

17. Identifying, by the one or more hardware processors, at the user interface, the negotiable instrument whose service fee and payment amount correspond to the difference between the excess of the amount of the negotiable instrument over the available monetary balance of the financial account; providing, by the computer processor, a plurality of remediation options at the user interface, including an option to pay the payment amount; 17. The method of claim 16, further comprising:

20. processing, by the one or more hardware processors, one or more rules to determine at least one of the service fee and the duration; The method of claim 15 further comprising:

Images