Patent Application
20220230153
The present disclosure generally relates to payment automation services. Specifically, the present disclosure generates to a payment automation service that includes a data enrichment tool configured to enrich data contained in payment files received from payees.
According to an embodiment, a computer-implemented method processes a payment request from a customer. Payment data is received from a customer. The payment data includes transactional data for payments to be made on behalf of the customer to payment recipients. The transactional data specifies payment amounts and identifies the payment recipients. A payment key is determined from the payment data. A data repository is accessed based on the payment key. Supplemental payment data is retrieved from the data repository. A payment signal is transmitted to a payment computer system (e.g., computerized check printing system, credit card network, etc.) to effect payment to the recipients in accordance with the payment data and the supplemental payment data.
According to an embodiment, a computer-implemented method processes a payment request from a customer. The method includes receiving, from an accounts payable system, by a payment manager logic of a bank computing system comprising at least one processor and non-transitory computer-readable media, the computer-readable media having embodied thereon the payment manager logic, a payment file. The payment file includes payment data from a commercial enterprise customer. The payment file includes transactional data for payments to be made on behalf of the commercial enterprise customer to payment recipients, wherein the payment data is associated with a parent company or a subsidiary of the commercial enterprise customer, or combination thereof. The transactional data includes payment amounts and payment recipient data on behalf of the parent company, the subsidiary, or the combination thereof. The method includes determining whether a customer profile associated with the parent company or the subsidiary of the commercial enterprise customer comprises a data enrichment configuration, the data enrichment configuration provided by the customer via a graphical user interface structured to interact with payment manager logic. The method includes determining, via the payment manager logic, a plurality of segment collections in the payment file, each segment collection comprising a plurality of elements delimited by an opening syntactic tag and a closing syntactic tag. The method includes generating, via the payment manager logic, a payment key associated with the customer profile according to metadata and specific segments of the payment file. Generating the payment key includes determining, from the metadata of the payment file, a customer identification number associated with the customer profile. Generating the payment key includes determining a payment method identification value from a first specific element identified based on a first opening syntactic tag and a first closing syntactic tag, the first specific element residing within the plurality of elements. Generating the payment key includes identifying a data enrichment key designated by the customer in the data enrichment configuration, wherein the data enrichment key is located within a customer-designated segment of the plurality of segment collections, wherein the customer-designated segment is identified by a second opening syntactic tag and a second closing syntactic tag. The payment key includes the customer identification number, the payment method identification value, and the data enrichment key. The method includes locating, via a data enrichment tool and based on the data enrichment key and the determination that the customer provided the data enrichment configuration, a data structure corresponding to the data enrichment key. The method includes retrieving, via the data enrichment tool, supplemental payment data comprising logistics data from the data structure corresponding to the data enrichment key. The method includes enriching, via the data enrichment tool, the payment file with the supplemental payment data from the data structure corresponding to the data enrichment key. The method includes transmitting, via the payment manager logic, a payment signal to a payment computer system to effect payment to the recipients in accordance with the payment data, the payment key, and the supplemental payment data.
According to an embodiment, a computer system which includes a processor, a memory and computer-readable media processes a payment request from a customer according to computer-implemented methods described herein.
According to an embodiment, a computer-executable medium or media has instructions embodied thereon that, when executed by a processor, carry out computer-based operations to process a payment request from a customer according to computer-implemented methods described herein.
According to example embodiments, a data enrichment tool is provided for a payment automation service. The payment service is configured to send payments to recipients responsive to instructions received from a customer (e.g., a commercial enterprise). In an example embodiment, the payment service is provided by a bank and the customers have accounts at the bank from which funds are sent to the recipients. The data enrichment tool may allow customers to store logistical information for the payments in a computer system operated by the payment service rather than providing such information in payment instruction files the customers deliver to the payment service each time payments are made. The data enrichment tool may be used to provide processing and routing data that is not provided by the customers' accounts payable systems. The data enrichment tool may be used to enrich payment files received from the customer with the appropriate additional content. This enrichment may be completed prior to any payment-specific processing.
Referring first to
Bank computer system 110 may include network interface logic 120, account management logic 122, payment manager logic 124, data storage system 128, and payment interfaces 130. Network interface logic 120 may be used to establish connections with computer systems 112 and to permit users to access accounts in system 110 by way of network 118. For example, such an interface may be used to receive bulk transfers of data from the customers, for example, payment files specifying various payments to be made to recipients. The network interface logic 120 may also be used by customers to interact with the payment manager logic 124. For example, network interface logic 120 may comprise one or more web servers that provide a graphical user interface (e.g., a series of dynamically-generated web pages) for customers that access system 110 through the web. The graphical user interface may be used by the customer to interact with the payment manager 124. For example, the graphical user interface may be used by the customer to configure one or more profiles for the payment manager logic 124. In other embodiments, the profiles may be configured by a customer service employee of the bank on behalf of the customer.
The account management logic 122 may be configured to perform account processing to process transactions in connection with the accounts of the account holders, such as account debits and credits to checking and savings accounts, credits and debits to home mortgage and home equity accounts, credits and debits to student loan accounts, and so on. For example, in the context of checking accounts, the transactions may also include electronic bill payment transactions in which monies from the checking account of the user are used to pay bills received by the user. The account management logic 122 may also be configured to perform processing in connection with other activities associated with the servicing and maintenance of the accounts of the account holders. The account management logic 122 may access and update information stored in the data storage system 128, which stores details regarding financial institution accounts including information for each financial transaction that occurred.
The payment manager logic 124 provides a payment automation service. As previously indicated, the payment manager logic 124 may be configured to receive electronic payment files from customers for processing. To process these payments, the payment manager logic 124 may utilize transactional payment information and logistical payment information. The transactional payment information comprises information about who is getting paid, how much, what the payment is for, and so on. The logistical payment information comprises information about message formats, delivery methods, payment system IDs, and so on.
In an exemplary embodiment, the transactional payment information is included in a payment file received from the customer. The payment files may be generated by an accounts payable systems operated by the customer (e.g., internal accounting systems, enterprise resource planning systems, treasury workstations, in-house solutions, and so on). Commercially available accounts payable systems often natively support basic transactional payment data, thereby facilitating the process of extracting it for payment manager logic 124. Commercially available accounts payable systems often do not adequately support the logistical enrichment data.
The payment manager logic 124 includes a data enrichment tool 126. The data enrichment tool 126 may allow customers to store payment logistical information in the bank computer system 110, rather than providing it in the files they deliver to the payment manager logic 124. The payment manager logic 124 may then utilize data enrichment tool 126 to enrich the received file with the appropriate additional content. The enrichment may be completed prior to any payment method specific processing.
The payment interfaces 130 may include various types of interfaces 132-135 for various payment methods. Such payment methods may include, for example, regular check delivery, same day check delivery, domestic automated clearing house (ACH) delivery, international ACH delivery, credit card payment, and/or other payment methods. The interfaces 130 may include program logic configured to interface the bank computer system 110 with the computer system of the respective payment service/system.
Also shown in
Referring now to
In such a scenario, the customer may have a separate profile configured for each of the subsidiaries. For each subsidiary, the profile may include a customized check template that reflects, e.g., the name and address of the respective subsidiary. If the subsidiaries use multiple payment methods, then the customer may have a separate profile configured for each of the payment methods for each of the subsidiaries.
At step 202, the payment manager logic 124 receives payment data from a customer. The payment data may include transactional data for payments to be made on behalf of the customer to payment recipients. For example, the transactional data may specify payment amounts and identify the payment recipients.
At step 204, the payment manager logic 124 determines a payment key based on the payment data. In an example embodiment, the payment key is embedded in the payment file and may be extracted from the payment file. The payment key is used to access a data repository 127. In an example embodiment, the payment key may be used as an index to a lookup table. In other embodiments, the payment key may be used as an index to other more complicated data structures.
At step 206, the data enrichment tool 126 accesses a data repository 127 based on the payment key and retrieves supplemental payment data from the data repository 127. The supplemental payment data includes logistics data specifying logistics of making the payments to the payment recipients. The logistics data is data that is preconfigured by the customer (or by a customer service representative on behalf of the customer) and that is stored in the data repository 127 prior to receipt of the transactional data. For example, in the context of the present example, the logistics data may include a check template that includes the name and address of the subsidiary on behalf of whom the payment is being sent.
At step 208, the payment manager logic 124 transmits a payment signal to a payment computer system to effect payment to the recipients in accordance with the payment data and the supplemental payment data. For example, the payment manager logic 124 may transmit the payment signal via interface 132. The interface 132 may interface with a computerized automated check printing system to ensure that a check is printed in conformance with the template and is sent to the intended payment recipient. As other examples, the interface 132 may interface with computer systems associated with a credit card network, automated clearing house system, third-party proprietary payment networks, and so on.
Referring now to
Referring now also to
Conversely, assuming the customer has a profile configured, then the process proceeds to step 414. At step 414, the data enrichment tool 126 determines the field segment in the payment file that contains the data enrichment key. In an example embodiment, the data enrichment key may be contained in a customer-specified segment of the payment file. For example, the payment file may include various standard data segments, such as a segment for an organization name, a segment for an organization ID, a segment for a organization account ID, and/or other segments, and the customer may be given the ability to select one of these segments to be used as a data enrichment key. In an example where the data enrichment key is a customer-specified segment of the payment file, then, based on the customer ID, the data enrichment tool 126 may determine which data segment of the payment file is to be used as the data enrichment key. Such an arrangement may permit the arrangement of
At step 416, the data enrichment tool 126 extracts a value from the field that is determined to contain the data enrichment key. For example, if it is determined that the customer specified a company ID field as being the field that contains the data enrichment key, then the data enrichment key is set equal to the value contained in the company ID field. As will be appreciated, if the customer has N subsidiaries and has configured N different profiles for the different subsidiaries, then the company ID may have N different potential values for that customer.
At step 418, the payment method is determined. The payment method may be determined based on the payment method ID, which may be a standard field in the payment file. As previously indicated, in the embodiment of
Referring again to
At step 422, the payment file is enriched with the logistical data retrieved from the data repository 127.
In the example
Referring again to
As previously indicated, in some instances, enhanced remittance information may also be sent. Hence, as shown in
As has been indicated, the payment manager logic 124 may interface with a variety of different types of payment systems. Examples of such systems including check systems (CHK), same day check systems (SDC), domestic automated clearing house systems (DAC), international automated clearing house systems (IAC), credit card systems (CCR), and so on. As will also be appreciated, the data enrichment tool 126 may be used to enrich payment files with a variety of different types of data. Table 1 below provides examples of different types of logistical data that may be stored in the data repository 127 for the afore-mentioned payment types. As will be appreciated, other types of logistical data may also be stored for each of these payment types.
In an example embodiment, the payment manager logic 124 may further include a smart routing engine 140. In such an arrangement, the payment manager logic 124 may be configured to receive payment data from a customer, determine a payment key from the payment data, and use the payment key to retrieve supplemental payment data from a data repository 127, as previously described. However, with the routing engine 140, the routing engine 140 may be used to determine the payment method to be used based on the supplemental payment data (e.g., the recipient of the payee, the dollar amount of the transaction, etc.). For example, the customer may be permitted to leave blank the data segment for the payment method type, such that the routing engine is permitted to choose the most efficient (e.g., lowest cost to the customer) payment method. For example, if the recipient accepts credit card payments, then paying via credit card may be a lower cost alternative than paying by check (e.g., once credit card rewards programs are taken into account). However, if the recipient does not accept credit card payments, then the routing engine 140 may determine that payment needs to be sent via check. Hence, the customer may provide a payment file for a series of transactions without a payment method specified, and in each case the routing engine 140 may determine the most efficient payment method to be used. In other embodiments, other parameters may be taken into account, such as speed of delivery of the payment. For example, if the routing engine 140 determines that a payment is due on the current day, it may determine to use a same day checking payment method rather than a regular checking payment method. As another example, the routing engine 140 may perform routing based on foreign exchange currency conversion rates (e.g., by determining whether to use purchased currency versus whether to use available currency in a given jurisdiction). As another example, the routing engine 140 may perform routing based on country specific clearing times of ACH transfers. For example, if the clearing time in a given jurisdiction is five days instead of two days, then an alternative (e.g., quicker) payment mechanism may be utilized. In one embodiment, the customer may be provided with a user interface that permits the customer to configure business rules for processing payments. For example, the business rules may be configured to permit a payment-related parameter to be compared to a threshold, and then determine which payment channel should be used based on the results of the comparison. For example, in the previous example, the customer may configure a business rule that sets a threshold (e.g., three days), such that a first payment channel is used if the clearing time is below the threshold and a second payment channel is used if the clearing time meets exceeds the threshold. As another example, the customer may configure a business rule that sets a dollar value threshold, such that a first payment channel is used if the dollar value of the payment is below the threshold and a second payment channel is used if the dollar value of the payment meets or exceeds the threshold. As another example, the customer may configure a business rule that sets a payment urgency threshold, such that a first payment channel is used if the amount of time until the payment is due is below the threshold and a second payment channel is used if the amount of time until the payment is due meets or exceeds the threshold. Such a user interface may therefore allow the manner in which the routing engine 140 operates to be customized on a customer-by-customer basis.
The embodiments described herein have been described with reference to drawings. The drawings illustrate certain details of specific embodiments that implement the systems, methods and programs described herein. However, describing the embodiments with drawings should not be construed as imposing on the disclosure any limitations that may be present in the drawings. The present embodiments contemplate methods, systems and program products on any machine-readable media for accomplishing its operations. The embodiments of may be implemented using an existing computer processor, or by a special purpose computer processor incorporated for this or another purpose or by a hardwired system.
As noted above, embodiments within the scope of this disclosure include program products comprising non-transitory machine-readable media for carrying or having machine-executable instructions or data structures stored thereon. Such machine-readable media can be any available media that can be accessed by a general purpose or special purpose computer or other machine with a processor. By way of example, such machine-readable media can comprise RAM, ROM, EPROM, EEPROM, CD-ROM or other optical disk storage, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to carry or store desired program code in the form of machine-executable instructions or data structures and which can be accessed by a general purpose or special purpose computer or other machine with a processor. Combinations of the above are also included within the scope of machine-readable media. Machine-executable instructions comprise, for example, instructions and data which cause a general purpose computer, special purpose computer, or special purpose processing machines to perform a certain function or group of functions.
Embodiments have been described in the general context of method steps which may be implemented in one embodiment by a program product including machine-executable instructions, such as program code, for example in the form of program modules executed by machines in networked environments. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Machine-executable instructions, associated data structures, and program modules represent examples of program code for executing steps of the methods disclosed herein. The particular sequence of such executable instructions or associated data structures represent examples of corresponding acts for implementing the functions described in such steps.
As previously indicated, embodiments may be practiced in a networked environment using logical connections to one or more remote computers having processors. Those skilled in the art will appreciate that such network computing environments may encompass many types of computers, including personal computers, hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and so on. Embodiments may also be practiced in distributed computing environments where tasks are performed by local and remote processing devices that are linked (either by hardwired links, wireless links, or by a combination of hardwired or wireless links) through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
An exemplary system for implementing the overall system or portions of the embodiments might include a general purpose computing computers in the form of computers, including a processing unit, a system memory, and a system bus that couples various system components including the system memory to the processing unit. The system memory may include read only memory (ROM) and random access memory (RAM). The computer may also include a magnetic hard disk drive for reading from and writing to a magnetic hard disk, a magnetic disk drive for reading from or writing to a removable magnetic disk, and an optical disk drive for reading from or writing to a removable optical disk such as a CD ROM or other optical media. The drives and their associated machine-readable media provide nonvolatile storage of machine-executable instructions, data structures, program modules and other data for the computer. It should also be noted that the word “terminal” as used herein is intended to encompass computer input and output devices. Input devices, as described herein, include a keyboard, a keypad, a mouse, joystick or other input devices performing a similar function. The output devices, as described herein, include a computer monitor, printer, facsimile machine, or other output devices performing a similar function.
It should be noted that although the diagrams herein may show a specific order and composition of method steps, it is understood that the order of these steps may differ from what is depicted. For example, two or more steps may be performed concurrently or with partial concurrence. Also, some method steps that are performed as discrete steps may be combined, steps being performed as a combined step may be separated into discrete steps, the sequence of certain processes may be reversed or otherwise varied, and the nature or number of discrete processes may be altered or varied. The order or sequence of any element or apparatus may be varied or substituted according to alternative embodiments. Accordingly, all such modifications are intended to be included within the scope of the present disclosure as defined in the appended claims. Such variations will depend on the software and hardware systems chosen and on designer choice. It is understood that all such variations are within the scope of the disclosure. Likewise, software and web implementations of the present disclosure could be accomplished with standard programming techniques with rule based logic and other logic to accomplish the various database searching steps, correlation steps, comparison steps and decision steps.
The foregoing description of embodiments has been presented for purposes of illustration and description. It is not intended to be exhaustive or to limit the disclosure to the precise form disclosed, and modifications and variations are possible in light of the above teachings or may be acquired from this disclosure. The embodiments were chosen and described in order to explain the principals of the disclosure and its practical application to enable one skilled in the art to utilize the various embodiments and with various modifications as are suited to the particular use contemplated. Other substitutions, modifications, changes and omissions may be made in the design, operating conditions and arrangement of the embodiments without departing from the scope of the present disclosure as expressed in the appended claims.
This application is continuation of U.S. application Ser. No. 14/102,334, filed on Dec. 10, 2013, which is incorporated herein by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14102334 | Dec 2013 | US |
| Child | 17004576 | US |
