Patent Publication Number: US-2017352013-A1

Title: Systems and Methods for Managing Rules Associated With Transaction Settlement Procedures

Description:
FIELD 
     The present disclosure generally relates to systems and methods for managing settlement rules associated with transaction settlement procedures in payment networks, wherein the settlement rules, based on parameters associated with issuers and/or acquirers, define interaction procedures for the payment network during settlement of transactions. 
     BACKGROUND 
     This section provides background information related to the present disclosure which is not necessarily prior art. 
     Payment account transactions are employed ubiquitously in commerce, whereby consumers purchase products (e.g., goods and/or services), through use of payment accounts. Those parties involved in the payment account transactions employ authorization and settlement procedures to ensure sufficient funds and/or credit are available to satisfy the transactions, and then coordinate the movement of funds between the involved parties. Settlement procedures are followed by and between acquirers, payment networks, and issuers to finalize payment account transactions through debiting funds and delivering funds to the appropriate ones of the acquirers and issuers. Each acquirer and/or issuer, interacting with a payment network during settlement procedures, defines rules based on issuer and/or acquirer information and preferences. Payment networks further maintain certain rules for acquirers and/or issuers that dictate the procedures followed. The rules are generally created by the payment network through complex and extensive static forms, which are completed, in total, by the acquirers and/or issuers, for each change to information or preference(s). The forms are, in turn, manually entered into a settlement rules data structure maintained by the payment network. 
    
    
     
       DRAWINGS 
       The drawings described herein are for illustrative purposes only of selected embodiments and not all possible implementations, and are not intended to limit the scope of the present disclosure. 
         FIG. 1  is a block diagram of an exemplary system of the present disclosure suitable for use in creating and updating settlement rules; 
         FIG. 2  is a block diagram of a computing device that may be used in the exemplary system of  FIG. 1 ; 
         FIG. 3  is a flowchart describing an exemplary method, that may be implemented in connection with the system of  FIG. 1 , for creating a settlement rule using the rules engine of the present disclosure; 
         FIGS. 4-10  are exemplary interfaces, including portions of a dynamic net settlement information form (NSIF), and which may be displayed to a user on a computing device in connection with the system of  FIG. 1  and/or the method of  FIG. 3 , for providing parameters of settlement rules; and 
         FIGS. 11 and 12  are exemplary interfaces including further portions of the dynamic NSIF, which may be displayed to a user on a computing device in connection with the system of  FIG. 1  and/or the method of  FIG. 3 , for providing relationships between an advisement type and a media type. 
     
    
    
     Corresponding reference numerals indicate corresponding parts throughout the several views of the drawings. 
     DETAILED DESCRIPTION 
     Exemplary embodiments will now be described more fully with reference to the accompanying drawings. The description and specific examples included herein are intended for purposes of illustration only and are not intended to limit the scope of the present disclosure. 
     Settlement of payment account transactions is subject to multiple procedures, which are defined by rules, and which may in turn be based on information and/or preferences (broadly, parameters) solicited from and provided by the issuers and/or acquirers involved in the transactions. The parameters vary between different issuers and acquirers depending on, for example, the extent of their involvement in payment account transactions, their locations, currencies involved, use of agents, etc. Uniquely, the systems and methods herein are capable of managing intake of parameters from the issuers and/or acquirers through the use of derived data collection. In particular, a settlement rules engine interacts with issuers and/or acquirers to solicit necessary parameters, by presenting and/or modifying a dynamic electronic form, based on business rules and/or parameters previously supplied by the issuers and/or acquirers. In this manner, the managing of such parameters is driven by the issuers and/or acquirers, specific to settlement profiles of the issuers and/or acquirers (including the provided parameters). The settlement rules engine is then able to coordinate with an in-use settlement data structure to integrate and/or employ certain rules included therein, which may be defined by the issuers&#39; and/or acquirers&#39; parameters (i.e., received via the electronic form), whereby subsequent settlement procedures are defined, at least in part, by the parameters. 
       FIG. 1  illustrates an exemplary system  100 , in which one or more aspects of the present disclosure may be implemented. Although the system  100  is presented in one arrangement, other embodiments may include the parts of the system  100  (or other parts) arranged otherwise depending on, for example, regional groupings of parts of the particular system, transactional roles employed in the system, particular parties included in the system and associated with transactions therein, etc. 
     The system  100  generally includes a merchant  102 , acquirers  104   a  and  104   c , a payment network  106 , and issuers  108   a - c , each coupled to (and in communication with) network  110 . The network  110  may include, without limitation, a local area network (LAN), a wide area network (WAN) (e.g., the Internet, etc.), a mobile network, a virtual network, and/or another suitable public and/or private network capable of supporting communication among two or more of the parts illustrated in  FIG. 1 , or any combination thereof. For example, network  110  may include multiple different networks, such as a private payment transaction network made accessible by the payment network  106  to the acquirers  104   a  and  104   c  and the issuers  108   a - c  (broadly, banking entities) and, separately, the public Internet, which may provide interconnection between the merchant  102  and the acquirers  104   a  and  104   c , etc. 
     The system  100  also includes separate regions A, B, and C. The network  110  serves to enable communication between the merchant  102 , the acquirers  104   a  and  104   c , the payment network  106 , and the issuers  108   a - c  across the multiple regions A, B, and C. The regions A, B, and C do not limit communication and/or transactions between parts of system  100 , but rather serve, for example, as boundaries indicated in any conventional manners (e.g., geographic, organizational, functional, etc.). The boundaries may further play one or more roles in determining behavior of the parts of system  100  during settlement. For instance, issuer  108   c  in region C (e.g., an English speaking region, etc.) may prefer that advisements be in English (i.e., a parameter defined by the issuer  108   c ), while the acquirer  104   a  in region A may prefer that advisements be in Spanish or some other language. Regional differences may also affect other aspects of settlement, by business rules of the payment network  106  and/or by parameters of the issuers  108   a - c  and/or acquirers  104   a  and  104   c , such as currency, input sources, licensing restrictions, countries, transfer agents, agent settings, and/or other parameters (as discussed more below). 
     It should be appreciated that the regions A, B, and C may be any different type of geographical, organizational, or functional division of parts of the system  100  (or other parts not shown). In particular, regions as used herein may be defined by area codes, postal codes, states, territories, countries, continents, etc. Alternatively (or additionally), regions may be defined by other logical or organizational divisions as well, such as separate divisions or business units of a company, separate agencies in a governmental entity, or the like (whereby such regions may even overlap in geography). Different regions may suggest that different parameters will be provided by particular issuers and/or acquirers, or not. 
     Generally in the system  100 , a consumer (not shown) completes purchase transactions for products with the merchant  102  (or with other merchants) using a payment account associated with the consumer. Specifically, the consumer, from region A in this example, initiates a transaction by presenting a payment device to the merchant  102  in region C, for example. The merchant  102 , in turn, reads the payment device and/or otherwise receives payment account information from the consumer, and then communicates an authorization request to the acquirer  104   c  (i.e., the acquirer associated with the merchant  102  in region C), as shown in  FIG. 1 , by reference to path  116 . The acquirer  104   c , in turn, communicates the authorization request through the payment network  106  (e.g., through MasterCard®, VISA®, Discover®, American Express®, etc.) to the issuer  108   a  (i.e., the issuer associated with the payment account of the consumer in this example). The issuer  108   a  then sends a reply (i.e., authorizing or declining the transaction) back to the merchant  102 , along the path  116 , which permits the merchant  102  to conclude or end the transaction. 
     If the transaction is authorized (and concluded by the merchant  102 ), the transaction is later settled by and between the parts of system  100 , generally in combination with multiple other transactions involving the acquirer  104   c  and/or issuer  108   a . In particular, the merchant  102  sends its payment account transactions in a batch file to the acquirer  104   c , for example, at the end of the day, or within a predefined interval. The batch file includes pertinent information for each transaction to the merchant  102 , including, for example, an account number, an amount of the transaction, a merchant ID, etc. In turn, the acquirer  104   c  reconciles the sent transactions and sends them on to the payment network  106  (i.e., to a clearing aspect of the payment network  106 ), etc. The payment network  106  then settles the transactions by debiting funds from appropriate accounts at the issuer  108   a  (as defined by clearing records received from the acquirer  104   c ) and crediting the funds to accounts associated with the acquirer  104   c  for the net amount of the transactions, less any interchange and/or network fees charged by the payment network  106 . Finally, the issuer  108   a  records the transactions against the accounts issued to its customers (including the customer in the above example), and the acquirer  104   c  credits the merchant&#39;s account. This also applies to transactions involving the acquirer  104   a  and issuers  108   b - c.    
     As part of the above, the payment network  106  abides by established settlement procedures defined by settlement data structure  112 , as it interacts with the issuer  108   a  and/or the acquirer  104   c  to process the batch file. The procedures are based on settlement rules, which are, in turn, based on business rules of the payment network  106  and/or parameters provided by the issuer  108   a  and/or the acquirer  104   c  (e.g. preferred currency, preferred language, preferences for communication methods/media, etc.). Furthermore, the acquirer  104   c  (and the acquirer  104   a ) and the issuer  108   a  (and the issuers  108   b - c ) are parties to agreements which further govern settlement procedures and/or rules with the payment network  106 . 
       FIG. 2  illustrates an exemplary computing device  200  that can be used in the system  100 . The computing device  200  may include, for example, one or more servers, workstations, personal computers, laptops, tablets, smartphones, PDAs, etc. In addition, the computing device  200  may include a single computing device, or it may include multiple computing devices located in close proximity or distributed over a geographic region, and configured to function as described herein. However, the system  100  should not be considered to be limited to the computing device  200 , as described below, as different computing devices and/or arrangements of computing devices may be used. In addition, different components and/or arrangements of components may be used in other computing devices. 
     In the exemplary embodiment of  FIG. 1 , each of the merchant  102 , the acquirers  104   a  and  104   c , the payment network  106 , and the issuers  108   a - c  are illustrated as including, or being implemented in, computing device  200 , coupled to the network  110 . Further, the computing devices  200  associated with these parts, for example, again may include a single computing device, or multiple computing devices located in close proximity or distributed over a geographic region, and configured to function as described herein. 
     Referring to  FIG. 2 , the exemplary computing device  200  includes a processor  202  and a memory  204  coupled to (and in communication with) the processor  202 . The processor  202  may include one or more processing units (e.g., in a multi-core configuration, etc.). For example, the processor  202  may include, without limitation, a central processing unit (CPU), a microcontroller, a reduced instruction set computer (RISC) processor, an application specific integrated circuit (ASIC), a programmable logic circuit (PLC), a gate array, and/or any other circuit or processor capable of the functions described herein. 
     The memory  204 , as described herein, is one or more devices that permit data, instructions, etc., to be stored therein and retrieved therefrom. The memory  204  may include one or more computer-readable storage media, such as, without limitation, dynamic random access memory (DRAM), static random access memory (SRAM), read only memory (ROM), erasable programmable read only memory (EPROM), solid state devices, flash drives, CD-ROMs, thumb drives, floppy disks, tapes, hard disks, and/or any other type of volatile or nonvolatile physical or tangible computer-readable media. The memory  204  may be configured, as one or more data structures, to store, without limitation, issuer settlement profiles (e.g., biographical data, issuer preferences, etc.), acquirer settlement profiles (e.g., biographical data, acquirer preferences, etc.), transaction data, batch files, business rules, settlement procedures, internet-based interfaces (e.g., as defined by internet-based applications, websites, etc.), and/or other types of data (and/or data structures) suitable for use as described herein. 
     Furthermore, in various embodiments, computer-executable instructions may be stored in the memory  204  for execution by the processor  202  to cause the processor  202  to perform one or more of the functions described herein, such that the memory  204  is a physical, tangible, and non-transitory computer readable storage media. Such instructions often improve the efficiencies and/or performance of the processor  202  that is performing one or more of the various operations herein. 
     In the exemplary embodiment, the computing device  200  includes a presentation unit  206  that is coupled to (and in communication with) the processor  202  (however, it should be appreciated that the computing device  200  could include output devices other than the presentation unit  206 , etc.). The presentation unit  206  outputs information (e.g., settlement parameter interfaces, etc.), visually, for example, to a user of the computing device  200 , such as user  122  associated with issuer  108   b  in the system  100 , etc. It should be further appreciated that various interfaces (e.g., as defined by internet-based applications, websites, etc.) may be displayed at computing device  200 , and in particular at presentation unit  206 , to display certain information. The presentation unit  206  may include, without limitation, a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic LED (OLED) display, an “electronic ink” display, speakers, etc. In some embodiments, presentation unit  206  includes multiple devices. 
     The computing device  200  also includes an input device  208  that receives inputs from the user (i.e., user inputs) such as, for example, selections of certain settlement parameters (e.g., currencies, advisement media, address, licensing, country of operation, etc.), etc. The input device  208  is coupled to (and in communication with) the processor  202  and may include, for example, a keyboard, a pointing device, a mouse, a stylus, a touch sensitive panel (e.g., a touch pad or a touch screen, etc.), another computing device, etc. Further, in various exemplary embodiments, a touch screen, such as that included in a tablet, a smartphone, or similar device, behaves as both a presentation unit and an input device. 
     In addition, the illustrated computing device  200  also includes a network interface  210  coupled to (and in communication with) the processor  202  and the memory  204 . The network interface  210  may include, without limitation, a wired network adapter, a wireless network adapter, a mobile network adapter, or other device capable of communicating to one or more different networks, including the network  110 . Further, in some exemplary embodiments, the computing device  200  includes the processor  202  and one or more network interfaces incorporated into or with the processor  202 . 
     Referring again to  FIG. 1 , the payment network  106  includes a rules engine  118  specifically configured, by executable instructions, to manage parameters received from the issuers  108   a - c  and/or the acquirers  104   a  and  104   c . The payment network  106  also includes a working data structure  120  that is configured to store business rules associated with the payment network  106 , as well as the parameters received by the rules engine  118  from the issuers  108   a - c  and/or the acquirers  104   a  and  104   c  and settlement rules queued to be loaded to the settlement data structure  112  (i.e., settlement rules generated by the rules engine  118 ), etc. 
     While the rules engine  118 , the settlement data structure  112 , and the working data structure  120  are illustrated as separate, standalone entities from the payment network  106 , it should be understood from the dotted circle in  FIG. 1  that the settlement data structure  112 , the rules engine  118 , and the working data structure  120  may be included together in the payment network  106 . In addition, as shown, the rules engine  118  is separate from, yet interacts with and/or is in communication with the settlement data structure  112  (which stores settlement data and, in particular, settlement profiles for each of the acquirers  104   a  and  104   c  and the issuers  108   a - c  employed in settlement as described above). This segregation, however, is not required in all embodiments. Further, in one or more embodiments, the working data structure  120  may be omitted, whereby the rules engine  118  interacts directly with the settlement data structure  112  (via one or more application programming interfaces (APIs), etc.). 
     The settlement rules and/or parameters, as indicated above, may relate to and/or include a variety of different aspects of the procedures by which transactions are settled by and between the parts of system  100 . Such aspects may include, without limitation, currency types (e.g., U.S. dollar, Venezuela&#39;s bolivar, etc.), region, country licenses, country or license requirements/restrictions (e.g., based on U.S. embargos, etc.), transaction types (e.g., cross border, domestic, etc.), times at which settlement is executed (i.e., settlement cycles), settlement service criteria, settlement paths (e.g., direct, consolidated, etc.), involved financial institutions and/or agents, input sources, financial institution account numbers and/or formats, transfer agent information (e.g., name, type, location, accounts, etc.), settlement service accounts, delivery channels, advisements (e.g., advisement message types, media, delivery channels, etc.), etc. Apart from, or in combination, a number of business rules (including certain metrics) are defined by the payment network  106 , as aspects, to govern the settlement procedures, which may be impacted, or not, by the parameters provided by the issuers  108   a - c  and/or the acquirers  104   a  and  104   c.    
     It should be appreciated that any of the above aspects, whether identified as parameters or rules, associated with the issuers  108   a - c  and/or the acquirers  104   a  and  104   c  (or the payment network  106 ), may be the subject of the operations described herein. 
     Generally, the rules engine  118  interacts with one or more users associated with the issuers  108   a - c  and/or the acquirers  104   a  and  104   c  in soliciting and/or receiving the parameters as described herein. As shown in  FIG. 1 , for example, the issuer  108   b  includes the user  122  (e.g., an employee, manager, administrator, etc.), associated with a workstation computing device  124  (consistent with computing device  200 ). As the issuer  108   b  determines that certain parameters are to be added or changed, the user  122  interacts with the rules engine  118 , via one or more interfaces (e.g., requests to create/modify parameter(s), etc.). In particular, the rules engine  118  is configured to cause one or more interfaces, which include an electronic form or a net settlement information form (NSIF), to be displayed to the user  122 , at the workstation computing device  124 . The NSIF is a dynamic form, which is employed to gather parameters from user  122  (or other users) in order to create settlement rules that are consistent with the parameters of the issuer  108   b , for example, (and the business rules of the payment network  106 ). 
     As the user  122  provides parameters (broadly, responses) to the rules engine  118 , via the interface(s), the rules engine  118  is configured to dynamically alter the interface(s) to include content of the NSIF based on responses (broadly, parameters) received from the user  122 . Additionally, or alternatively, the dynamic feature of the interface(s) may be defined by the interface(s) itself (by executable instructions), whereby the rules engine  118  may be omitted, at least in part, from altering the interface(s). In either event, because the interface(s) are altered to include content as a result of the user&#39;s responses, the interface(s) operate to limit the potential for soliciting unnecessary or unused information and/or for confusing the user  122 . In addition, while the interface(s) are described above to solicit parameters from a user, the rules engine  118  may be configured (in certain embodiments) to cause the interface(s) to be displayed in a “read only” mode, whereby the user is able to review, but not edit, the parameters associated with the respective issuers  108   a - c  and/or acquirers  104   a  and  104   c.    
     Finally, the rules engine  118  is configured to store rules, created based on business rules and/or parameters, in the working data structure  120 . The rules engine  118  is configured to further invoke one or more APIs to load the rules from the data structure  120  to the settlement data structure  112 , thereby implementing the rules for use in subsequent settlement procedures (without interrupting the use of the settlement data structure  112 ). The rules may be created and/or stored in the working data structure  120  for use by the rules engine  118  by direct writes and/or updates to the data structure  120  (and any database tables or the like therein or otherwise). Alternatively, the rules engine  118 , the settlement data structure  112 , and/or the working data structure  120  may include a front-end interface (e.g., a command line interface, a graphical user interface (GUI), etc.) that enables a user to create and/or update rules stored in the settlement data structure  112  and/or the working data structure  120 . 
       FIG. 3  illustrates an exemplary method  300  for creation of a settlement rule by the user  122 , at the issuer  108   b , using the rules engine  118  of the payment network  106  in the system  100 . The exemplary method  300  is described as implemented in the rules engine  118  of the payment network  106 . However, the method  300  is not limited to the rules engine  118 , or more generally, the system  100 , but may be implemented in other parts of system  100  or in other systems (not shown). Further, while the method  300  is described with reference to issuer  108   b  (to the exclusion of the other issuers  108   a  and  108   c  and the acquirers  104   a  and  104   c  illustrated in  FIG. 1 ), for ease of reference, nothing should be understood to limit method  300 , or the systems and methods herein, to the issuer  108   b , or any aspect of issuer  108   b  (including the user  122  and the workstation computing device  124 ). Further still, the exemplary method  300  is described herein with reference to the computing device  200 . The methods herein, however, should not be understood to be limited to the exemplary system  100  or the exemplary computing device  200 , and likewise, the systems and the computing devices herein should not be understood to be limited to the exemplary method  300 . 
     When the issuer  108   b  applies to be on-boarded to the payment network  106 , or otherwise seeks to change one or more aspects, as described above, the user  122 , via workstation computing device  124  (and, thus, the issuer  108   b ), requests, at  302 , to create and/or modify a parameter (or multiple parameters) associated with the issuer  108   b . The user&#39;s request may be provided, for example, to add a new account, add an agent, modify an existing account, modify an advisement, or add/modify any one or more of the aspects, described above, that may alter and/or affect procedures related to settlement, e.g., settlement rules, etc. In general, the request is provided via one or more internet-based interfaces, for example, an internet-based application, website, etc., for which access is controlled by credentials specific to the issuer  108   b  and/or the user  122 , as is conventionally known. 
     The rules engine  118 , in turn, receives the request to create and/or modify the parameter, at  304 , from the user  122 , via the one or more internet-based interfaces. 
     Upon receipt of the request, the rules engine  118  causes, at  306 , an interface to be displayed to the user  122  at workstation computing device  124 . The interface includes, in this embodiment, at least a portion of a dynamic form, such as, for example, the NSIF described above. The user  122 , in turn, provides responses to inquiries included in the interface, at  308 , which may be understood herein to be, broadly, parameters. In particular, depending on the particular interface, the user  122  may provide a response in the form of a text entry, a selection from a drop-down menu, a selection of a radio button and/or check box, etc. The rules engine  118  receives the response from the user  122 , at  310 , and determines, at  312 , whether to alter the interface (or a different interface), based on the response received from the user  122  (including either a parameter provided by the user  122  and/or a selection/input to the interface that is not a parameter, i.e., input that is not in response to an inquiry). The determination, at  312 , may be based on a structure of the NSIF and/or one or more business rules associated with the payment network  106 , which determine what parameters are necessary and/or desired in view of the response(s) from the user  122 . 
     Alternatively, the NSIF may be generated in such a way that it includes logic which dynamically alters the form based on user inputs, without contacting the rules engine  118 . That is, the rules engine  118  may embed the enforcement of at least some form alteration rules within the form itself so that the changes occur automatically based on embedded logic within the form (e.g., the rules engine  118  is embedded, at least in part, in the form; etc.). 
     When the rules engine  118  determines that an alteration is needed or desired, the rules engine  118  alters an interface (e.g., one of the interfaces being displayed and/or a subsequent interface, etc.), at  314 , and then causes the altered interface to be displayed to the user  122 , at  306 . The altered interface may be displayed immediately, or upon selection or advancement to the altered interface by the user  122 , etc. This may be repeated multiple times, creating a loop through which the rules engine  118  alters (or does not alter) the interface(s) forming the NSIF, to guide the user  122  to provide complete parameters, as desired or needed, to the payment network  106  in a dynamic and efficient manner. The interface, or interfaces, may be altered, by the rules engine  118 , by adding or omitting particular inquiries/pages, by adding or omitting selectable responses (e.g., included in a drop-down menu, etc.) and/or by altering which responses are required or not, etc. 
       FIGS. 4-9  illustrate exemplary interfaces, which include different parts of an exemplary NSIF (form  400 ), as well as alterations to the interfaces by the rules engine  118 , based on certain business rules and/or responses from the user  122 , as described herein. The method  300  will be described in more detail next in connection with the interfaces. 
     Initially, the form  400  is accessed through a general landing interface (not shown), which is caused to be displayed to the user  122  as part of an internet-based application, website, etc. The landing interface provides the user  122  with the option to select between creating a new settlement rule/parameter, viewing and/or editing a current settlement rule/parameter and/or advisement, copying a current settlement rule/parameter and/or advisement, etc. The landing interface may also provide “pending change” information to inform the user about settlement rules/parameters which have recently had changes made and may require viewing or approval from the user  122 . As suggested above, the landing interface is accessible by credentials specific to the issuer  108   b  and/or the user  122 , as is conventionally known. 
       FIG. 4  illustrates the exemplary form  400  with a currency tab  402  selected. The form  400 , as shown in  FIG. 4 , is caused to be displayed to the user  122  at workstation computing device  124 , when the user selects to create a new settlement rule/parameter. It should be appreciated that the exemplary form  400  is substantially consistent, at least in part, with other interfaces that may be displayed to the user  122 , for example, when other options (e.g., when other tabs of the form  400  such as the settlement options tab, bank details tab, advisement tab, summary tab, etc.) are selected from the landing interface by the user  122  (or even when other forms are displayed). In such embodiments, when a modification is requested, for example, certain prior responses (broadly, parameters) may be auto-filled and/or pre-filled into the other interfaces or forms, based on responses, during a prior session, from the acquirer, issuer, user, etc. 
     As shown in  FIG. 4 , the currency tab  402  enables the user  122  to select parameters which control aspects of the currency used in settlement. The currency tab  402  includes a currency menu  412 , which enables the user  122  to select a currency type for use in the settlement, and a settlement type menu  414 , which enables the user  122  to select whether the settlement is domestic or a different type, such as a foreign settlement. In response, the rules engine  118  may alter the currency menu  412  in the form  400  to include valid currencies based on business rules and/or settings, which limit and/or define valid currencies for the issuer  108   b . And, similarly, the rules engine  118  may alter the form  400 , in the settlement type menu  414 , to include the list of only valid settlement types (broadly, responses) based on the currency selected and other business rules and/or settings. 
     Once the user provides the responses in currency tab  402 , the user is able to proceed to further tabs in the form  400 . Specifically, the form  400  includes multiple additional tabs: a settlement options tab  404 , a bank details tab  406 , an advisement tab  408 , and a summary tab  410 . In  FIG. 4 , these tabs are shown as unselected (or not selectable). As such, these tabs may not be available for viewing yet, for example, based on options available to the user  122 , or based on certain responses not being provided yet. For instance, in order for the settlement options tab  404  to be available, a selection of currency and/or settlement type may be required, i.e., the user  122  may need to select a currency at currency menu  412  and/or a settlement type from the settlement type menu  414  on the currency tab  402 , in order for the next tab to be selectable. As shown in  FIG. 4 , the currency menu  412  and the settlement type menu  414  are annotated with an asterisk to indicate to the user  122  that a response to each is required in order to proceed further. It should be appreciated that a page of the interface  400  may include required and not-required response(s) (which may be decided by prior responses). In one example, there may be different options for settlements on the settlement options tab  404  based on the response to the currency menu  412  and/or the type of settlement at menu  414 , such that the responses in currency tab  402  are required in order for the rules engine  118  to properly populate the settlement options tab  404 . 
     It should be understood that the tabs shown on form  400  are exemplary. In certain embodiments, the form  400  may have more, fewer, or different tabs available for user selection. And, in alternative embodiments, the form  400  may represent separate parts thereof in different manners, such as, for example, in a sequence of interfaces, etc. Further, the form  400  may include selectable buttons that enable the user  122  to advance to the next section of the form  400  or to go back to the previous section (broadly, interfaces), i.e., navigate within different interfaces of the form  400 . Furthermore, responses may be provided in the form  400  via boxes, radio buttons, pulldown menus, or text entry fields, etc. 
       FIG. 5  illustrates the exemplary form  400  with the settlement options tab  404  selected, which offers the user  122  a choice between a direct settlement button  502  and a consolidate settlement button  504 . In this exemplary instance, the choice between the two buttons  502  and  504  determines a bank that is used for the settlement, whether that be the payment network  106  with direct settlement (e.g., via the payment network&#39;s bank partner, or via the payment network  106  acting as a bank, etc.), or a different bank with a consolidated settlement. The direct settlement button  502  may only be available to a subset of acquirers/issuers (broadly customers), such as “principle” customers. For example, with reference to  FIGS. 3 and 5 , upon selection of the direct settlement button  502  (which is received by the rules engine  118 , at  310 ), the rules engine  118  may determine a change is needed, at  312 , alter the form, at  314 , and cause the bank details tab  406  to be activated or selectable (broadly, displayed) in form  400 , at  306 . Alternatively, upon selection of the consolidate settlement button  504 , the form  400  may require the user  122  to provide a valid ICA. In addition, the form  400  may require that the provided ICA already be set up for the selected settlement service with valid bank account information. Then, after selection of a valid ICA, the rules engine  118  may determine a change is needed, at  312 , alter the form, at  314 , and cause the advisement tab  408  (or another tab) to be activated or selectable (broadly, displayed) in form  400 , at  306 . 
       FIG. 6  illustrates the exemplary form  400  with the bank details tab  406  selected. The bank details tab  406  may be activated or selectable, for example, when the user  122  selects direct settlement at the settlement options tab  404 . Then, the particular fields requested/collected from the user  122  at the tab  406  will generally depend on business rules defined at the rules engine  118 . For example, each bank could have a unique set of “flex fields/bank fields” that are required (which can be managed in the business rules at the bank currency/combination). 
     As also shown in  FIG. 6 , an additional tab, i.e., the clearing criteria tab  602 , is appended to the form  400  as a selectable tab. For example, with additional reference to the method  300 , the rules engine  118  may determine, at  312 , based on a response from the user  122 , that a change was needed, and then alter the form at  314  to append the additional tab and cause the altered form  400  to be displayed, at  306 , to the user  122  at workstation computing device  124 . In this example, the clearing criteria tab  602  is added in response to the selected currency and settlement type on the currency tab  402  (and when a regional default is not selected). In some embodiments, particular settlement types and/or currencies may be configured to have clearing criteria, which may cause the clearing criteria tab  602  to be included in the form  400 , or not. 
     With further reference to  FIG. 6 , the bank details tab  406  includes several user inputs allowing a user to respond with a bank to use for the settlement. The inputs include a bank name field  604 , a country field  606 , a bank routing number field  608 , and an account number field  610 . The bank name field  604 , the bank routing number field  608 , and the account number field  610  are text entry boxes, while the country field  606  is a drop-down menu. Again, it should be understood that the input types shown in the bank details tab  406  are merely exemplary, not limiting, and that other input methods may be used in the form to gather the necessary information. 
     It should be appreciated that the content of the bank details tab  406  may be different (or altered by the rules engine  118 , at  314 ) based on input provided in prior or other tabs in the form  400 , such as, for example, the currency tab  402  and the settlement options tab  404 . As described, for example, in some embodiments the bank details tab  406  may only be available if a direct settlement type is selected previously. In particular, for a direct settlement response in the settlement options tab  404 , the user  122  may be required to enter bank information into the bank name field  604 , the country field  606 , and other fields, such as the bank routing number field  608 . Field entries, such as the drop-down menu of the country field  606 , may be altered, by the rules engine  118  (at  314 ) with valid data entries based on the business rules and/or the responses from other tabs. Other fields may have rules-based requirements. For example, the bank routing number field  608  may require nine (9) numeric characters for a valid response, etc. The fields may also be defined by business rules, and altered by the rules engine  118 , to be required or optional based on the prior responses and/or business rules. 
     In some embodiments, the rules engine  118  may alter, at  314 , the form  400  to include the bank details from a data structure based on the bank and/or ICA selected previously. 
       FIG. 7  illustrates the exemplary form  400  with the clearing criteria tab  602  selected. The tab  602  enables the user  122  to set limitations regarding what clearing transactions will qualify for clearing for the settlement setup. An exemplary clearing criteria group display  702  is shown, which includes a settlement ID indicator  704  and selection boxes  706  and  708  for setting whether the defined criteria group “1” applies to issuing activities (via box  706 ) or acquiring activities (via box  708 ). In some embodiments, both boxes may be checked to indicate that the criteria group “1” applies to both types of activities. Further, the clearing criteria group display  702  includes entry boxes  710  for setting a range of issuer account numbers to which the clearing criteria applies. The user  122  may also enter a Bank Identification Number (BIN) in box  712  and a product code in box  714 . The field entries (e.g., entry boxes  710 ,  712 , and  714 , etc.) may be altered, by the rules engine  118 , based on business rules and/or responses provided on previous tabs, such as the account range boxes  710  being limited based on the accounts to which the issuer  108   b  has access. Additionally, again, the rules engine  118  may alter, at  314 , the form  400  by populating the field entries with responses available from previous tabs and/or data structures, such as the working data structure  120 . 
     It should be understood that multiple criteria groups (e.g., criteria group “1” in  FIG. 7 ) may be created and/or applied as settlement rules/procedures. In one example, the issuer  108   b  may set up a criteria group based on a range of account numbers and a transaction currency, which would result in transactions including both of those factors qualifying for the criteria group. Alternatively, the issuer  108   b  may set up a first criteria group with a defined account range and then a second criteria group with a defined transaction currency. Transactions including either factor would trigger either the first or the second criteria group. 
       FIG. 8  illustrates the exemplary form  400  with the advisement tab  408  selected. The advisement tab  408  allows the user  122  to select parameters that determine how advisements associated with the settlement occur. For instance, the advisement tab  408  includes an advisement type menu  802  (including options as described below), a delivery method menu  804 , a recipient name field  806 , a recipient destination field  808 , a live date field  810 , and an email status notification field  812 . By providing responses to one or more of inquiries in tab  408 , the user  122  is able to create an advisement, which is sent by the payment network  106  as part of the settlement process. The advisement may be a summary, detailed or otherwise, and may be sent to one or multiple recipients (individually, or in a group) in a variety of manners (e.g., email, short-message-service (SMS), etc.). 
     In addition in the form  400  illustrated in  FIG. 8 , the user  122  may add additional recipients for the advisements through use of an add recipient link  814 , and may add additional advisements through use of an add advisement setup link  816 . It should be understood that the advisement tab  408  may be optional and/or the rules engine  118  may alter the content/options displayed under the tab  408  based on one or more responses provided on other tabs, such as the settlement options tab  404  and/or the bank details tab  406 . Further, business rules may be used, by the rules engine  118 , to alter the form  400 , by limiting the fields/options and/or by populating certain fields of the advisement tab  408  with responses available from previous tabs and/or data structures, such as the working data structure  120 . For example, when the user  122  selects, for instance, a particular delivery method from menu  804 , the rules engine  118  may alter the form  400  to include different input fields to be completed by the user  122 . If “email” is selected, the form  400  may include a recipient destination field  808 , under the tab  408 , for entering an email address. If instead “fax” is selected as a delivery method, the form  400  may include a different input entry field, which requires entry of a fax number. Further, in another example, a drop-down menu associated with the advisement type menu  802  may be altered to include only valid advisement types for the issuer  108   b . In another example, a drop-down menu associated with the recipient field  806  may include only eligible persons approved by the issuer  108   b  to receive advisements. Further, the rules engine  118 , based on prior responses and/or rules, may alter the form  400  to require some responses, while not requiring other responses. 
     With continued reference to  FIG. 8 , by selecting link  814  or  816 , the exemplary form  400  may further be updated with additional input entries reflecting the link selection. For instance, by selecting to add another recipient, via link  814 , the rules engine  118  may alter the form  400 , at the tab  408 , to include a recipient name text entry and a recipient destination text entry. And, by selecting to add advisement setup, via link  816 , the rules engine  118  may alter the form  400  to include additional advisement text entries or other responses. 
       FIG. 9  illustrates the exemplary form  400  with the summary tab  410  selected. The summary tab  410  includes a summary of all of the responses previously defined throughout the prior tabs of the form  400  (included in collapsible sections). A settlement service section  902  is shown, which includes a summary of responses about the settlement service generally, along with collapsed sections, including a currency section  904 , a settlement options section  906 , and a bank details section  908 . When each collapsed section is selected, by the user  122 , via the workstation computing device  124 , it is expanded to display the summary of response(s) provided, by the user  122 , under the respective tab. It should be appreciated that the form  400 , and the particular display in  FIG. 9 , in other embodiments, may include, when the summary tab  410  is selected, a variety of different formats including the same and/or different indicative of the user&#39;s responses. 
     Referring again to  FIG. 3 , when the rules engine  118  determines, at  312 , that no further alterations to the interface (or interfaces) are needed and that the responses (e.g., parameters, etc.) to the interface are complete (in general, or as to the “required” responses), the rules engine  118  confirms the interface is complete, at  316 . This may include, for example, transmitting a confirmation to the user  122  to confirm that the responses to the interface are ready to be submitted to the payment network  106 , by the user  122 , for use in creating the desired settlement rule. In response to the confirmation, the user  122  then submits the responses to the interface, at  318 , to the rules engine  118 . For example, the user  122  may select an “OK” button or a “Submit” button to cause the user&#39;s responses to the interface to be submitted to the rules engine  118 . In some embodiments, the user  122  may also have the option, at  318 , to make further changes as necessary or desired to the responses to the interfaces prior to submission to the payment network  106 . 
       FIG. 10  illustrates the form  400  in condition for approval (e.g., an approval interface associated with the form  400 , etc.), or for secondary approval, and includes an approval section  1002 . In so doing, the form  400  may be displayed to a second user, similar to the user  122 , at a workstation computing device, by the rules engine  118 , as a further verification before the rules engine  118  proceeds to create and/or modify the settlement parameters, as indicated by the user&#39;s responses. The second user then performs a review of the entire form  400 . The second user is separate from the first user  122 , such that any data provided in the form  400 , for the issuer  102   b , is accurate and complete. 
     As shown in  FIG. 10 , the approval section  1002  in the form  400  includes a box  1004  for the user to verify the responses are complete and/or sufficient, along with collapsed summaries of the further responses provided by the user  122 . Any of the collapsed sections may be selected to review the responses, as indicated by the title on each collapsed section. Further, at this point, the form  400  includes buttons  1006  for the user  122  (or another user) to approve or reject the settlement parameter creation or modification. Finally, a submit button  1008  is provided for selection when completing the form  400 . It should be appreciated that final approval and/or rejection of the settlement parameter creation or modification may be based on various business rules associated with the payment network  106 , the issuer  108   b , etc. In some embodiments, the approval portion of the form  400  is displayed to the second user only after the first user has completed the entire form  400 . Here, the rules engine  118  may require that at least two users review and approve the completed form  400  prior to any action being taken based on the form  400 . 
     Referring again back to  FIG. 3 , at  320 , based on the further approval, the rules engine  118  receives the submission and stores the responses to the interfaces in the data structure  120 . 
     At one or more regular or irregular intervals, or at some interval (or immediately) after receiving and/or storing the submission to the data structure  120 , the rules engine  118  attempts to load the user&#39;s indicated parameters, in the form of settlement rules, to the settlement data structure  112 . In particular, the rules engine  118  invokes a settlement data structure API, at  322 . The settlement data structure API is a service-based API that enables customers (e.g., the issuer  108   b , etc.) with active settlement profiles to retrieve and update their settlement parameters. The rules engine  118  employs the settlement data structure API to save a rule based on the submitted parameters to the working data structure  120 , at  324 . In turn, the payment network  106  uses the settlement data structure  112  in further settlement operations involving the issuer  108   b , as described above. In this exemplary embodiment, the API includes exposed interface calls via a web service (e.g., a representational state transfer (REST) web service) that enables the NSIF and/or other external programs to create new rules with the rules engine  118  and/or review and change rules that have already been created using Hypertext Transfer Protocol (HTTP), or the like. The API may provide data to the NSIF and/or other external programs in the form of Extensible Markup Language (XML) documents, JavaScript Object Notation (JSON) documents, or the like. Use of the API enhances data integrity within the system and reduces risk of data loss, mistakes, and/or other issues stemming from other static form processes. 
     As should be appreciated, a variety of different interface(s), including various forms, etc., may be employed to solicit responses from one or more users to create and/or modify settlement parameters for acquirers and/or issuers. 
       FIGS. 11 and 12  illustrate alternative advisement tabs that may be used in the systems and methods herein.  FIG. 11  illustrates an advisement interface  1100 , which, for example, consistent with exemplary method  300 , may permit the user  122  to view, add, update, etc., the advisements related to settlement, by the issuer  108   b . The advisement interface  1100  includes section  1102 , which includes an identifier, a name and a MPS status of the issuer  108   b . The interface  1100  further includes section  1104 , which permits the user  122  to enter, without limitation, parameters including live date and time to implement the change, batch designation which indicates that the changes requested by the user should be grouped, and a reason for the change, etc. 
     The interface  1100  of  FIG. 11  also includes section  1106 , which permits the user  122  to select options to view, add, update, delete, or backup advisement parameters for the issuer  108   b . Upon selection of one of the options, the rules engine  118  alters the next interface to be displayed based on the selection. For example, when the user  122  selects an “Add” option  1108 , the rules engine  118  alters the next interface to include the exemplary interface  1200 , as shown in  FIG. 12 , and causes the same to be displayed to the user  122  at workstation computing device  124 . 
     In turn, interface  1200  includes an advisement type section  1202 , which determines the type of the advisement to be delivered, and a “Receive When” section  1204 . The message type may include, without limitation Member Detail Advisement (MAD), Member Exception Advisement (MAE), Member Summary Advisement (MAS), member Value Date Advisement (MAV), Member No Activity Notification (MBN), Member Counterparty Advisement (MCA), Member Detail XML Advisement (MDX), Member Future Detail Report (MFD), Transfer Agent Detail Advisement (TAD), Transfer Agent Exception Advisement (TAE), Transfer Agent No Activity Notification (TAN), Transfer Agent Detail Reminder Advisement (TAR), Transfer Agent Summary Advisement (TAS), Transfer Agent Value Date Advisement (TAV), Transfer Agent Counterparty Advisement (TCA), Transfer Agent Detail XML Advisement (TDX), and Transfer Agent Future Detail Report (TFD), etc. 
     Each of the advisement types is indicative of a particular type of summary, report, notice, etc., related to settlement, which are selectable from a drop down menu  1206  of the interface  1200 , from which the advisement type is filled into the adjacent field. For example, when the user  122  selects the “TAD” advisement type, the description “Transfer Agent Detail Advisement” is filled into the adjacent field. The “Receive When” section  1204  includes checkboxes, which, when checked, indicates when the issuer  108   b  prefers for the recipients to receive the advisement, whether for a debit position and/or for a credit position. 
     The interface  1200  also includes a media section  1208 , which enables the user  122  to determine the media type associated with the currently displayed Advisement/Media relationship. The media type may include email, fax, mail, SMS, voicemail, etc., which, when selected from an associated drop-down menu  1210 , is filled into the adjacent field. In one or more embodiments, the available media for selection from the menu  1210  may be altered and/or changed, by the rules engine  118  (at  314 , for example), depending on the type of advisement message selected at  1202 . In relation to the media section  1208 , the interface  1200  includes a priority section  1212 . The priority section  1212  enables a user to select a priority level for the current Advisement/Media relationship rule. The priority value may be used to indicate priority, visually, to a receiver of an advisement message associated with the current advisement/media relationship rule (broadly, parameter). Additionally, a higher priority value may indicate that an advisement message has a higher chance of being sent to and seen by an intended receiver of the advisement message. A retries section  1214  is also included, which enables the user  122  to select a number of times to retry sending an advisement message, for example, before halting attempts to send the advisement. 
     With continued reference to  FIG. 12 , a media destination section  1216  is further included in the interface  1200 . The media destination section  1216  enables the user  122  to specify the destination of an advisement message associated with the current advisement/media relationship rule. In the interface  1200 , the media destination section  1216  includes a destination entry field and a “use prefix” entry field. The destination entry field permits the user  122  to enter contact information for the designated recipient, such as an email address, a phone number, a fax number, etc. The available destinations may be dependent on the advisement type and/or media type, such that the rules engine  118  may alter the available and/or acceptable options. The “use prefix” entry field indicates whether the rules engine  118  should use an area code on a local phone number or a country code on an international phone number. The rules engine  118 , for example, may alter the interface  1200  to permit selection of the “use prefix” entry field for only certain types of media, or advisement types, according to what is selected above. The interface  1200  further includes a contact information section  1218 , which enables the user  122  to enter an attention for inclusion in the message and even select one or more persons to receive the advisement (e.g., by selection from a contacts listing, etc.). Further, the interface of  FIG. 12  may include a number of required fields, as indicated by a greyed-out “OK” button  1220 . The button  1220 , in this exemplary embodiment, is only filled-in and selectable, when the required information in the interface  1200  is supplied. 
     The interfaces  1100  and  1200  are employed in combination, in various embodiments, to receive responses from the user  122  to create, modify and/or update settlement parameters, etc. The interfaces  1100  and  1200  are consistent with the method  300  and may be used therewith. 
     Moreover, it should be appreciated that various different interfaces, or inquiries included therein, may be different (as compared to those referred to herein) in other embodiments, while still being used in method  300 , or in the system  100 , or in different methods and/or systems contemplated herein. 
     In various embodiments, parameters entered to the interface(s) (as defined by the electronic form) (broadly, responses) are saved, by the rules engine  118 , and associated with the issuer  108   b , for example. The user-provided parameters may be stored, by the rules engine  118 , per field or per page in the same or a different format, or, in some embodiments, only when the user submits a page or navigates between multiple pages, interfaces, or tabs within the interface. In numerous embodiments, therefore, the user  122  is able to enter certain parameters (i.e., responses), exit an interface, and return at a later time to continue and/or complete filling parameters into the interface. In at least one embodiment, parameters entered and/or filled to interfaces are not saved, unless the user  122  specifically submits the interfaces, such as, for example, by selecting a “submit” or “approve” button in the interface. 
     In view of the above, the systems and methods herein may enable users to create and update settlement rules with the guidance of dynamically generated forms. Users based at acquirers and/or issuers may access the system to create or update one or more settlement parameters through responses to one or more forms (e.g., the NSIF form, etc.). As the user provides responses to the form, the form may be altered to include and/or exclude additional inquiries, prompts or fields from being displayed to the user as necessary. When the user completes the form, the associated settlement parameters is created, modified, or updated. In this manner, users can easily and efficiently create settlement parameters (broadly, rules) for use by and between the payment network and/or the acquirers/issuers to minimize redundant and/or unnecessary responses, and to reduce confusion in creating, modifying, and/or updating settlement parameters. 
     Again and as previously described, it should be appreciated that the functions described herein, in some embodiments, may be described in computer executable instructions stored on a computer readable media, and executable by one or more processors. The computer readable media is a non-transitory computer readable storage medium. By way of example, and not limitation, such computer-readable media can include RAM, ROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium that can be used to carry or store desired program code in the form of instructions or data structures and that can be accessed by a computer. Combinations of the above should also be included within the scope of computer-readable media. 
     It should also be appreciated that one or more aspects of the present disclosure transform a general-purpose computing device into a special-purpose computing device when configured to perform the functions, methods, and/or processes described herein. 
     As will be appreciated based on the foregoing specification, the above-described embodiments of the disclosure may be implemented using computer programming or engineering techniques including computer software, firmware, hardware or any combination or subset thereof, wherein the technical effect may be achieved by: (a) receiving a request related to a settlement rule, the request related to creating the settlement rule and/or modifying the settlement rule; (b) causing an interface to be displayed to a user, said interface defining at least part of a settlement form and including a first inquiry related to a first settlement parameter associated with the entity; (c) receiving a first response to the first inquiry from the user; (d) altering one of the interface and/or a subsequent interface of the settlement form to include a second inquiry related to a second settlement parameter associated with the entity, based on the first response; (e) causing the altered one of the interface and/or the subsequent interface to be displayed to the user, whereby one or more subsequent inquiries in the settlement form are consistent with prior responses; and (f) generating and/or altering at least one settlement rule, based on at least the first response, for the entity. 
     Exemplary embodiments are provided so that this disclosure will be thorough, and will fully convey the scope to those who are skilled in the art. Numerous specific details are set forth such as examples of specific components, devices, and methods, to provide a thorough understanding of embodiments of the present disclosure. It will be apparent to those skilled in the art that specific details need not be employed, that example embodiments may be embodied in many different forms and that neither should be construed to limit the scope of the disclosure. In some example embodiments, well-known processes, well-known device structures, and well-known technologies are not described in detail. 
     The terminology used herein is for the purpose of describing particular exemplary embodiments only and is not intended to be limiting. As used herein, the singular forms “a,” “an,” and “the” may be intended to include the plural forms as well, unless the context clearly indicates otherwise. The terms “comprises,” “comprising,” “including,” and “having,” are inclusive and therefore specify the presence of stated features, integers, steps, operations, elements, and/or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and/or groups thereof. The method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed. 
     When a feature is referred to as being “on,” “engaged to,” “connected to,” “coupled to,” “associated with,” “included with,” or “in communication with” another feature, it may be directly on, engaged, connected, coupled, associated, included, or in communication to or with the other feature, or intervening features may be present. As used herein, the term “and/or” includes any and all combinations of one or more of the associated listed items. 
     Although the terms first, second, third, etc. may be used herein to describe various elements, components, regions, layers and/or sections, these elements, components, regions, layers and/or sections should not be limited by these terms. These terms may be only used to distinguish one element, component, region, layer or section from another region, layer or section. Terms such as “first,” “second,” and other numerical terms when used herein do not imply a sequence or order unless clearly indicated by the context. Thus, a first element, component, region, layer or section discussed below could be termed a second element, component, region, layer or section without departing from the teachings of the example embodiments. 
     The foregoing description of exemplary embodiments has been provided for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure. Individual elements or features of a particular embodiment are generally not limited to that particular embodiment, but, where applicable, are interchangeable and can be used in a selected embodiment, even if not specifically shown or described. The same may also be varied in many ways. Such variations are not to be regarded as a departure from the disclosure, and all such modifications are intended to be included within the scope of the disclosure.