Patent Application
20060015454
The present invention is directed to communications and data processing and, more specifically, to processing transactions with distributor-client layer hierarchy and payment facilitation for multiple distributors.
Operational management of contractual and transactional interactions between buyers, sellers, financial institutions and others involved in the exchange of merchant offerings (e.g., goods and/or services) for purposes of commerce have typically been labor and time intensive. Generally, the processes of managing transactions between business entities have been unduly burdensome and inefficient.
Financial institutions and other transaction processing entities employ transaction processing parameters that are unique to each entity. In addition, these transaction processing parameters typically need to be kept separate (and confidential), relative to other financial institutions. Often, transaction processing is dependent upon these parameters, which are specific to a particular financial institution involved in financing the transaction. In this regard, transaction processing for portions of a transaction that are related to a financial institution has generally been limited to implementation by a processing engine or system employed by the financial institution participating in the transaction.
When a transaction reaches the payment step, financial institutions for different parties to the transaction must interact with each other. This interaction typically involves complex agreements and associations that facilitate the transfer of funds. At times, there can be delays in payment or disputes regarding terms of payment. In addition, this process is highly susceptible to error. Interaction complexity, delay and error, as well as a multitude of other characteristics of transaction payment can cost one or more parties to a transaction (including financial institutions) a significant amount of funds.
Most industries are quite competitive and any cost savings are therefore important. Administrative costs are targeted for reduction as no revenue is directly generated from administrative functions. However, administrative costs associated with commercial transactions have been difficult to reduce in the current business environment with widely diffused data.
The above and other difficulties in the management and coordination of transactions have presented administrative and cost challenges to business entities involved in various aspects of transactions, including financial institutions and others.
The present invention is directed to overcoming the above-mentioned challenges and others related to the types of devices and applications discussed above and in other applications. The present invention is exemplified in a number of implementations and applications, some of which are summarized below.
According to an example embodiment of the present invention, transactions are managed using a multi-layer processing approach involving the automatic processing of client-based transactions with transaction processor-implemented functions involving an administrated processing system with a distributor layer of sponsoring entities, such as financial institutions, buyer sponsors and seller sponsors. Profile and/or contract information is stored in connection with a variety transactions and used to audit characteristics of the transactions and, where appropriate, facilitate financial characteristics of the transactions. Transaction processing fees are automatically assessed, with funds associated with the fees being selectively allocated for administration and distribution functions. In some applications, one or more parties to the transaction providing financing services also assesses fees, with these financing fees also being allocated as part of the transaction.
In another example embodiment, fees are automatically assessed as a function of various transaction characteristics and contractual-type agreements between transaction clients and distributors, and between each distributor and a system administrator. Funds from the assessed fees are automatically allocated to the system administrator, distributors and, where appropriate, transaction clients as relative to the contractual-type agreements.
According to another example embodiment of the present invention, an automated transaction processing system processes transactions on behalf of a plurality of distributors that contract with a controller party implementing the automated transaction processing system. The system includes client-layer functions including a client-layer auditor that audits transactions between contracting parties according to different sets of transaction rules. Each of the respective sets of transaction rules is defined as a function of a unique one of the plurality of distributors (e.g., defined with a distributor identification) and a business relationship (e.g., a contract) between the unique distributor and at least one of the contracting parties. A client-layer payment processor that facilitates payment for each audited transaction as a function of the client-layer auditor's audit of the transaction. That is, where the audit produces results upon which payment is to be authorized (e.g., the audit indicates that transaction conditions required for payment have been satisfied), the results can be used to authorize payment.
The system also includes distributor-layer functions including a distributor-layer controller that controls an implementation of the client-layer payment processor on behalf of each one of the plurality of distributors as a function of a business relationship (e.g., contract) between each distributor and the controller party. A distributor-layer payment processor assesses fees against each distributor for transactions processed on behalf of each distributor, and facilitates funds transfer to cover the assessed fee. Assessing fees against teach distributor involves, for example, assessing a fee against each transaction, with the fee being collected as directed by the distributor, which may involve the collection of a fee from a contracting party and/or from the facilitated payment.
The above summary of the present invention is not intended to describe each illustrated embodiment or every implementation of the present invention. The figures and detailed description that follow more particularly exemplify these embodiments.
The invention may be more completely understood in consideration of the detailed description of various embodiments of the invention in connection with the accompanying drawings, in which:
While the invention is amenable to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not necessarily to limit the invention to the particular embodiments described. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention as defined by the appended claims.
The present invention is believed to be applicable to a variety of different types of communications and financial process management approaches, and has been found to be particularly useful for applications involving the operational implementation and application of layered transaction processing rules and processes to transactions, payments and related aspects thereof. While the present invention is not necessarily limited to such approaches, various aspects of the invention may be appreciated through a discussion of various examples using these and other contexts.
According to an example embodiment of the present invention, a rules-based transaction approach is implemented with multiple distributor entities for automatically processing transactions for transaction parties. Each distributor facilitates transactions between transaction parties (e.g., buyers and/or sellers), where at least one of the transaction parties is a client of the distributor. A host processor manages transactions on behalf of each distributor, using transaction processing rules tailored to each distributor and, where appropriate, a particular transaction party, in processing that distributor's transactions. The host processor carries out processing aspects of transactions between two or more of the transaction parties as a function of the business rules for at least one distributor facilitating the transaction for a transaction party and, where appropriate, business rules for one or more of the transaction parties.
In some applications, the host processor carries out aspects of transactions between two or more transaction parties as a function of business rules for different distributors, where each of the different distributors facilitates transactions on behalf of at least one transaction party. In this regard, the host processor provides generally distinct financial processing functions for each distributor and, where appropriate, functions as a generally silent partner to the transaction, relative to each distributor's clients.
In another example embodiment of the present invention, a central transaction management system uses business rules (e.g., included in profile information) associated with distributors to process transactions between parties sponsored by the distributors. In some applications, the transaction parties are also sponsored by financial institution distributors, which facilitate the processing of financial aspects of transactions. Sponsoring, in this regard, may generally relate to an arrangement between a distributor and a client, wherein the client and distributor transact for processing aspects of transactions for merchant offerings (i.e., goods and/or services) between the client and another party. As relative to examples herein involving tiered transaction relationships, with a host processor operating transaction processing characteristics on behalf of a plurality of distributors, sponsored parties in that context refer to, e.g., clients of the distributors, the clients including transaction parties such as buyers and sellers as discussed above.
When the central transaction management system receives transaction information, the information is parsed for identifying characteristics that can be associated with sponsoring distributors. When these identifying characteristics match a particular distributor, the central transaction management system uses business rules for the distributor to process the financial transaction. In addition, when identifying characteristics for different parties to the transaction match different distributors, financial aspects of the transaction that are specific to each party are processed according to the each party's corresponding sponsoring distributor. Funds relating to the distributor are thus transferred according to the business rules associated with sponsoring distributor for each party and to the particular characteristics of the transaction.
In another implementation, the central transaction management system further uses business rules, associated with individual sponsored transaction parties, to process transactions involving the sponsored parties. Generally, each sponsoring distributor facilitates the gathering of business rules for the individual sponsored transaction parties, such as by directly soliciting the rules or by directing each party to supply business rules to the central transaction management system. Once the sponsored parties' business rules are established and made available to the central transaction management system (e.g., via storage local to and/or remote from the central transaction management system), transactions associated with a sponsored party are processed in accordance with those business rules.
When the central transaction management system receives transaction information, such as an invoice to be paid, that information is used to identify sponsoring distributors as well as the parties to the transaction. The transaction is then processed according to the business rules of the sponsoring distributors as well as the business rules of the sponsored parties to the transaction. These transaction party-specific business rules may be stored, for example, in a user profile that is accessible by the central transaction management system or separately under association with the specific sponsored transaction party to which the rules belong.
In some instances, the sponsoring distributor for a particular transaction party is identified as a function of the identity of the party and corresponding business rules for the party. For example, when a transaction party sets business rules to identify a particular sponsoring distributor, these business rules are implemented in selecting the sponsoring distributor. Correspondingly, the business rules for the distributor identified by the transaction party's business rules are used to process the transaction.
In other instances, two or more distributors specified by a particular party are included as participants in the transaction for one or more of a variety of functions. These specified distributors may include sponsoring and/or non-sponsoring distributors, and distributors of different types, such as transaction processing distributors and financial institutions. That is, a specified sponsoring distributor sponsors the particular party for management of transactions (via the central transaction management arrangement), where other specified distributors may be funds-providing institutions (e.g., banks), credit-issuing institutions, currency conversion institutions or others.
In applications involving multiple financial institutions for a common party, the central transaction management system interfaces with financial institutions in addition to each transaction party's sponsoring distributor. For instance, where a transaction party has primary banking functions with a non-sponsoring financial institution, a sponsoring financial institution, via the central transaction management system, facilitates the transaction by exchanging funds via the non-sponsoring financial institution. The sponsoring financial institution may further implement processing type fees via the central transaction management system, charged for facilitating the transaction.
In some instances, the central transaction management system interfaces directly with distributors that, from a hierarchical perspective, pass-through information received from one or more parties to the transaction. The central transaction management system uses transaction rules based on the transaction information received from a distributor. Effectively, the distributors use the central transaction management system to execute transaction-processing functions that are carried out using transaction-based rules specific to the particular distributor providing the transaction information.
In other instances, the central transaction management system is adapted to interface directly with parties to a transaction and to use transaction rules based on information received from one or more of the parties (i.e., without a sponsoring distributor). For example, a buyer or seller can interface with the central transaction management system using rules, implemented with the system, which are based on profile information for the particular buyer or seller. These parties may contract with a system administration entity, effectively acting as a sponsoring distributor in some regards, relative to the above discussion, to facilitate transactions in this manner.
In some implementations, the central transaction management system (or host processor as discussed earlier) works to keep separate the transaction rules for each distributor. Where appropriate, separate rules are also kept for transaction parties. Access to the transaction rules, and in general to the services of the central transaction management system, is restricted to the institution (or party) to which the rules belong. This restricted access approach may be implemented using, for example, encryption, passwords, tracking and other security-type measures typically implemented for data access and protection.
Business rules are stored using one or more of a variety of approaches. For example, a database accessible by a central transaction management system and having labels or other identifying characteristics that associate the business rules with a particular distributor can be used. This database can be physically local or remote to the central transaction management system, as long as the central transaction management system can access the database and control access to the database by other entities.
The administration processor (or the host processor) as discussed above can be implemented in a single location or across a variety of locations. Where appropriate, certain functionality of the central or host processor can be implemented at different accessible locations communicatively coupled to one another. In addition, functionality of the central or host processor can be implemented at various levels in transaction hierarchy, such as with a distributor or with transaction parties who are clients of and/or sponsored by distributors.
Turning now to the figures,
Distributor profiles are stored for each processing distributor, with the administration processor 110 or with an accessible database 112, and used by the administration processor in carrying out transaction processing functions for the processing distributors. The database 112 is optionally coupled to (or part of) the administration processor 110 and further may include a plurality of data storage arrangements at different locations. The administration processor 110 maintains separate (and secure) storage for these profiles by restricting access to the profiles by the processing distributors (or others such as transaction parties). Typically, the distributor profiles and other programmed characteristics of the administration processor 110 implement rules associated with contracts between the processing distributors and an administration party 140 that operates the administration processor.
The administration processor 110 interacts with a multitude of client parties 130-i on behalf of the processing distributors 120-N, with interaction with each client party facilitated as a function of profiles and a transaction processor implementation for the particular processing distributor with which each client party is associated. That is, transaction data (e.g., transaction-based documents such as invoices or other financial documents) provided by clients of a particular processing distributor is automatically associated with the processing distributor. The association of transaction data (and thus clients) with a particular processing distributor may involve, for example, using identification information provided with the transaction data for directly identifying a processing distributor or for identifying the client party and in turn using information in the distributors for associating the identified client party with a processing distributor.
Each transaction processor implementation in the administration processor 110 can be tailored in function to the needs of a particular processing distributor for which the transaction processing implementation is administered. In this regard, a multitude of separate transaction processing functions are carried out in parallel with each other by the administration processor 110, with each transaction processing function generally distinct from other transaction processing functions. From a visual perspective, each of the client parties 130-i view transaction interaction with the administration processor as effective direct interaction with the processing distributor with which the client party is engaged in a contractual relationship for transaction processing services. Furthermore, where transaction processing services include financial services, financial aspects of transactions are implemented in a confidential and distinct manner, relative to other (non-transaction-party) processing distributors and their respective transaction processor implementations.
Using an example transaction between a buyer client party 130 and a seller client party i and where processing distributor 120 sponsors buyer client party 130, the administration processor 110 is transparent in transaction document exchange and other interaction between the client parties and the processing distributor 120. That is, interaction between clients and the transaction processor implementation for the processing distributor 120 is carried out in a manner as would be directly carried out with the processing distributor 120. All interactions in such a transaction are characterized by and carried out as a function of agreements between the administration party 140 and the processing distributor 120; further, these agreements (e.g., as characterized in the distributor profile for the processing distributor 120) contemplate specific transaction processing relationships between the processing distributor 120 and the buyer client party 130. In certain applications, the distributor profiles for the processing distributor 120 (or other processing distributors) include separate and specific profiles for each client of the particular processing distributor, with the specific client profiles used in the implementation of the transaction processor for the processing distributor.
Continuing with the example transaction in the previous paragraph, the transaction processor implementation for the processing distributor 120 facilitates payment from, or on behalf of, the buyer client party 130 to client party i. In some applications, the transaction processor implementation facilitates payment by paying the client party i and extending credit to the buyer client party 130. In other applications, the transaction processor implementation facilitates payment by interacting with a financial institution specified by the buyer client party 130 in its profile information. In still other applications, the transaction processor implementation facilitates payment at the direction of the processing distributor 120 (i.e., using information specified in its distributor profile).
Certain example embodiments involving the transaction processing arrangement 100 implement sub-distribution approaches, where one or more of the client parties 130-i distribute, or sponsor, involvement with the administration processor 110 to other clients. This approach may be applicable, for example, where a client of a particular processing distributor sponsors another transaction party for using the administration processor 110. For example, using an example where the client party 130 uses a transaction processor implementation for the processing distributor 130, client party 130 may sponsor other client parties into use of the transaction processor implementation where the other client parties are privy to a common contract with the client party 130. Such a situation may arise, for example, where client party 130 is a seller and sponsors a buyer client party into use of the transaction processor implementation for processing invoices related to the particular transaction. Another example involves an application where a particular client party acts as a processing distributor to one or more sub-client parties, e.g., where the sub-client parties enter into a transaction with each other. The examples discussed below in connection with
In addition to the above examples, each transaction processor implementation is selectively carried out in a variety of manners, tailored to specific processing distributors and/or generalized across different processing distributors. For general information regarding transaction processing approaches and for specific information regarding transaction processing implementations that carried out by the administration processor 110 in connection with various example embodiments, reference may be made to the following patent documents, each of which is fully incorporated herein by reference: U.S. Pat. No. 5,910,896, No. 6,571,149, No. 6,697,702 and No. 6,704,612, all to Hahn-Carlson; and U.S. patent application Ser. No. 10/436,878 (USBA.101PA).
In another example embodiment, the administration processor 110 maintains data for business rules and processed transactions over time for a variety of purposes, such as for generating reports, tracking compliance and for taking appropriate action where errors or non-compliance occurs. For example, when a particular transaction is processed or when business rules are changed, the central processor monitors associated information and stores and/or processes the monitored information for these purposes.
The user profiles and/or business rules discussed herein in connection with
In another example embodiment of the present invention, the administration processor 110 provides a user interface for each distributor and adapted for interfacing with contracting parties specified by the distributor. The administration processor 110, through the user interface, facilitates contracting party access to the system using profile information for the contracting party (e.g., user name and password as provided by the distributor), thus providing access to the administration processor 110 by any contracting party granted access by the distributor.
The hierarchical relationships generally shown in
Distributors in the distributor layer and/or sub-distributor layer distribute processing functions of the transaction processing system 210 to clients in the client layer. The distributors may, for example, distribute transaction functions such as those related to the automatic processing of orders, invoices, shipment documents and financial transfer and/or credit functions. Referring to
By way of example, distributors shown include transaction processing Distributors A and B respectively at nodes 232 and 234, and financial distributors Bank A and B respectively at nodes 230 and 236. Bank A (230 provides financial processing functions, via the transaction processing system 210, to clients 1-N. The transaction processing distributors 232 and 234 provide, via the transaction processing system 210, transaction processing functions respectively to sub-distributors 1-2, clients A-i and, via sub-distributors 1-2, sub-clients A, B, 1 and 2. Bank B (236) distributes processing functions to banks including sub-banks 1 and 2, which in turn provide financial processing functions for sub-clients C, D, 3, and 4. While not shown, one or both of the distributor 232 and bank 236 may provide services both to sub-distributor entities as well as client entities.
Generally, fees are associated with transaction processing functions carried out by the transaction processing system 210 on behalf of distributors and sub-distributors, either directly as part of the transactions (e.g., by assessing a fee related to the processing of payment for a transaction) or by charging a fee based on use or other non-transaction specific basis. The fees may be separately assessed to one or more of the distributors, sub-distributors, clients or sub-clients, depending upon the particular transaction and any arrangement with the parties to the transaction, as defined in profiles, contract information or other data stored in the database 220. In addition, a source for the fees can also be defined in profiles stored in the database 220, and used together with authorization information to draw the fees.
For example, where distributor B (234) contracts with client A to process transactions on that client's behalf, an agreement between distributor B and client A is implemented by the transaction processing system 210 to assess a fee for transaction services rendered to client A. This fee may be transaction finance-based (e.g., a percentage of a financial transfer related to the transaction), based on a flat-fee service or otherwise implemented. Distributor B further is assessed a fee by the transaction processing system 210 for the services rendered thereby. In some applications, the fees are assessed and paid separately. In other instances, the transaction processing system 210 assesses fees directly to client A, withholds a portion of those fees owed by distributor B to the transaction processing system 210 and pays a remaining portion of the fees to the distributor B. In still other instances, fees assessed to client A (and other clients sponsored by distributor B) are paid directly to distributor B with a separate fee assessment carried out for paying for processing functions provided for distributor B, as a function of contract terms between distributor B and the transaction processing system 210.
In some example embodiments, the transaction processing system 210 is further adapted to interact with financial institutions for payment and/or settlement functions relating to transactions involving clients sponsored by distributors. For example, where Sub-bank 1 sponsors sub-client C into a transaction as a buyer purchasing goods from sub-client D (e.g., sponsored directly by the bank or by association with a transaction involving sub-client C), payment is effected to sub-client D with associated settlement extracted from sub-client C. Financial institutions for sub-clients C and D are used for these purposes, with funds transfer either happening directly between the financial institutions or via the transaction processing system 210, which may hold back a particular fee for the transaction and/or provide credit via which payment is made to sub-client D's financial institution on behalf of sub-client C. Where credit is provided, credit extension fees are assessed where designated by profiles or other processing rules, in addition to transaction-based fees. Information specifying such financial institutions from which payment may be drawn is stored in the database 220 in connection with profile information (and/or business rules) relating to each transaction and/or parties to the transaction.
In some applications, credit is provided by the transaction processing system 210 using an underwriting approach. The transaction processing system 210 (e.g., using a client-layer type auditor such as an auditor engine 250 as discussed below) audits a transaction between buyer and seller clients as a function of a credit term relating to the buyer and transaction rules specified by the controller party. Using the audit, the transaction processing system 210 is underwrites a cash flow from the buyer to the seller on behalf of the a controller party (e.g., a distributor) as a function of the audit. Fees for the underwriting are added to those fees assessed by the transaction processing system 210 for facilitating the transaction.
In another set of example embodiments, the transaction processing system 210 is adapted to facilitate credit extension to clients and/or distributors. In some embodiments, the transaction processing system 210 extends the credit directly (acting as a credit issuing institution), providing funds for use in payment and/or settlement functions for transactions. In other embodiments, the transaction processing system 210 indirectly facilitates the provision of funds, e.g., using outside financial institutions specified by clients and/or distributors. Where the transaction processing system 210 extends credit to clients via financial distributors, the credit extension, tracking and other processing functions are carried out using profile information for the financial distributors (e.g., stored in the database 220).
In some applications, the transaction processing system 210 is configured for settling financial institution issues relating to fees and/or other transaction characteristics. When a buyer and seller enter into a transaction, the transaction processing system 210 calculates the amount of funds to be collected from the buyer's bank and remitted to the seller's bank (e.g., where one or both banks function in the distributor layer). These funds are used to fund the payment that the seller's bank will make to the seller for all transactions that achieve payable status within a particular payment period (e.g., a network day) for the transaction processing system 210.
Once the amount of funds to be collected are determined, the transaction processing system 210 further acts to facilitate the collection of these funds in one or more of a variety of manners. For instance, the transaction processing system 210 may simply make the amount of funds known to parties to the transaction using conventional communications methods. In other instances, the transaction processing system 210 actively facilitates collection of these funds, at both payment and settlement aspects of transactions, e.g., as discussed above.
In one example, an electronic payment demand is submitted on an interval (e.g., at least daily) to the buyer's bank for all net monies due either to the transaction processing system or to the seller's bank when the buyer's bank has net funds due. An electronic payment demand is also submitted on an interval to the seller's bank for all net monies due either to the transaction processing system or to the buyer's bank when the seller's bank has net funds due. In addition, an electronic payment notice is submitted on an interval (e.g., at least daily) to the buyer's bank for all net monies due to the buyer's bank. The net monies due are contemplated after subtraction of funds due to either the transaction processing system or the seller's bank when the buyer's bank has net funds due. An electronic payment notice is also submitted to the seller's bank for all net monies due to the seller's bank. Similarly as above, these net monies due are contemplated after subtraction of funds due to either the transaction processing system or the buyer's bank when the seller's bank has net funds due.
Access to information at the database 220 is controlled in one or more of a variety of manners, with information made available to users selectively and in a variety of formats, depending upon the implementation. Various examples using this general approach are discussed below.
In one example embodiment, each distributor has access to the transactions naming their clients. By enabling such access, each distributor institution is granted access to perform customer service functions related to transaction processing for their clients within the transaction processing system. In addition, each distributor can maintain an overview of their net position with each of their customers to whom they are providing processing functions and, in some applications, issuing credit.
Financial distributors issuing credit to either buyers or sellers can also specify where credit-related information is retrieved from for use in a transaction. For example, the location from which credit drawdown advice is to be delivered can be specified. In addition, credit-issuing financial institutions can specify whether the drawdown advice is to include transaction details or simply be the aggregate of the transaction details for the reporting period. For the latter case, the transaction processing system 210 can be specified to be used as the detailed subledger to support the credit usage. In this sense, the transaction processing system 210 functions much like conventional credit-issuing institutions (including credit card issuing institutions), with the credit issuer being provided summary or detail information.
A variety of security-related functions are implemented with the transaction processing system 210, depending upon the application and the desired level of security. For example, in some implementations, data flowing to the transaction processing system 210 from distributors and/or clients is encrypted using standard encryption technologies. Similarly, data flowing from the transaction processing system 210 to distributors and/or clients can also be encrypted using standard encryption technologies. Communications between any distributed computing devices and the transaction processing system 210 can also be encrypted using standard encryption technologies. For instance, where transaction functions for different distributors are carried out at physically different locations, communication between these system implementations and the transaction processing system 210 is encrypted.
In addition to security-related functions for transaction communications, access to data within the transaction processing system 210 can also be controlled using security measures. For instance, profiles stored in the database 220 may include security type information, such as password and/or encryption information that users accessing the transaction processing system 210 may employ.
In another example embodiment of the present invention, a fee-based distributed transaction processing system is implemented for processing transactions between buyers and sellers with a sponsoring processing distributor setting business rules (e.g., contract information) by which the transactions are processed. This system may be implemented, for example, in connection with the administration processor 100 in
The fee-based system includes a data storage arrangement having at least one distinct database, and in some applications two or more databases at distinct or common locations. The data storage arrangement stores business rules for a multitude of transactions involving distinct transaction parties including buyers, sellers and processing distributors, and also stores user profiles for the transaction parties. The processing distributors sponsor at least one of a buyer and a seller for each transaction. In this regard, the fee-based system implements transaction processing for sponsoring distributors, for transactions executed between a buyer and a seller.
A transaction processing controller (e.g., transaction processing system 210) interacts with the distinct transaction parties for receiving profile information specified by the transaction parties, e.g., with each transaction party providing information such as a funds source, authorization for extracting or otherwise transferring funds and, where appropriate, rules by which transactions can be audited for payment approval. The transaction processing controller also interacts with the processing distributors for receiving business rules as specified by each processing distributor, and store the received profile information and business rules in the data storage arrangement.
An association engine (e.g., association engine 240) receives and associates transaction payment data with a processing distributor as a function of stored profile information for parties to a transaction to which the transaction payment data applies. That is, when transaction payment data such as an electronic invoice is received, the association engine accesses the data storage arrangement to retrieve profile information that can be used to associate the electronic invoice with a particular transaction. That association is used to retrieve business rules applicable to the particular transaction.
An auditor engine (e.g., auditor engine 250) audits payment of the received transaction payment data using business rules retrieved from the data storage arrangement as associated with a processing distributor by the association engine. For example, where business rules specify that payment for a transaction is to be authorized when receipt of goods and/or services is acknowledged, the auditor engine may use such a receipt (e.g., received from a buyer party) together with the business rules to audit payment of the transaction.
A transaction payment processor (e.g., transaction payment processor 260) uses an audit result together with profile information for at least one party to the transaction to facilitate payment for each audited transaction. For example, where the audit result includes a payment authorization, profile information specifying a financial institution account from which to draw payment or from which to draw down a credit line is used as a source of funds, with authorization information specified in the profile information used to access the funds.
The system also includes a fee payment processor (e.g., fee processor 270) that assess a fee against the distributor sponsoring a transaction party for each transaction, and that facilitates payment for the assessed fee, e.g., in a manner similar to that discussed in connection with the facilitation of payment by the transaction payment processor above. In some applications, the fee is assessed directly against the distributor, and in other applications, the fee is assessed against one or more parties to each transaction. In addition, the amount of the fee may be set in accordance with an agreement between an operator of the system and the distributor against whom the fee is assessed, and/or assessed as a percentage of a financial amount of the transaction.
In some applications, the transaction payment processor extends credit for payment of the transaction on behalf of one or more transaction parties. For example, the credit rating of a distributor sponsoring a particular transaction is selectively used (as dictated by business rules) to extend credit on behalf of a particular buyer when facilitating payment to a seller. Similarly, the credit rating of a seller is selectively implemented for extending credit on behalf of a buyer, to that seller. In a more direct approach, the credit rating of a buyer is used to extend credit to that buyer, for payment to a seller for a particular transaction. One or more of these approaches are thus selectively implemented, as indicated in appropriate transaction profiles.
In connection with the above example fee-based system, one or more of the association engine 240, auditor engine 250, transaction payment processor 260 and fee processor 270 are selectively implemented in connection with similar functions described in connection with other embodiments discussed herein. For example, the auditor engine 250 is selectively implemented with a client-layer auditor functions for processing transactions between clients on behalf of a distributor. The transaction payment processor 260 is selectively implemented with client-layer and/or distributor-layer payment processing functions for facilitating payment and/or for assessing fees for such transactions. The transaction processing system 210, in connection with one or more of the auditor engine and transaction payment processor 260, is selectively implemented with distributor-layer controller functions.
If a match between the transaction data and a distributor is found at block 330, transaction processing data corresponding to the match is loaded at block 340. In some instances, this loaded transaction processing information includes information exclusively provided by a distributor that is the subject of the match. In other instances, the loaded transaction processing data includes information for parties to the transaction in addition to the distributor that is the subject of the match (e.g., for specifying user preferences or profiles as discussed above). After the transaction processing data has been loaded, it is used to process the transaction data at block 350 for facilitating processing aspects of the transaction, such as by storing data, auditing invoices or approving payment.
While certain aspects of the present invention have been described with reference to several particular example embodiments, those skilled in the art will recognize that many changes may be made thereto without departing from the spirit and scope of the present invention, aspects of which are set forth in the following claims.
This patent document claims priority under 35 U.S.C. §119 to U.S. Provisional Patent Application No. 60/578,375, entitled “Financial Transaction Processing System and Approach” and filed on Jun. 9, 2004.
| Number | Date | Country | |
|---|---|---|---|
| 60578375 | Jun 2004 | US |
