U.S. patent application number 11/151747 was filed with the patent office on 2008-07-17 for financial institution-based transaction processing system and approach.
Invention is credited to Dean W. Hahn-Carlson.
Application Number | 20080172314 11/151747 |
Document ID | / |
Family ID | 46328262 |
Filed Date | 2008-07-17 |
United States Patent
Application |
20080172314 |
Kind Code |
A1 |
Hahn-Carlson; Dean W. |
July 17, 2008 |
Financial institution-based transaction processing system and
approach
Abstract
Transaction processing for financial institution-based
transactions is facilitated. According to an example embodiment of
the present invention, a transaction processing approach involves
the processing of financial aspects of a transaction between buying
and selling parties using transaction rules associated with a
sponsoring financial institution. Transaction-related information
is processed as a function of business rules associated with the
sponsoring financial institution to facilitate payment for the
transaction and the assessment of fees associated with the
transaction processing.
Inventors: |
Hahn-Carlson; Dean W.;
(Lilydale, MN) |
Correspondence
Address: |
CRAWFORD MAUNU PLLC
1150 NORTHLAND DRIVE, SUITE 100
ST. PAUL
MN
55120
US
|
Family ID: |
46328262 |
Appl. No.: |
11/151747 |
Filed: |
June 9, 2005 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
10437405 |
May 12, 2003 |
|
|
|
11151747 |
|
|
|
|
09259657 |
Feb 26, 1999 |
6571149 |
|
|
10437405 |
|
|
|
|
08748243 |
Nov 12, 1996 |
5910896 |
|
|
09259657 |
|
|
|
|
60578375 |
Jun 9, 2004 |
|
|
|
60379561 |
May 10, 2002 |
|
|
|
Current U.S.
Class: |
705/35 |
Current CPC
Class: |
G06Q 30/04 20130101;
G06Q 40/00 20130101; G06Q 40/12 20131203; G06Q 40/025 20130101;
G06Q 30/06 20130101; G06Q 10/08 20130101; G06Q 20/40 20130101 |
Class at
Publication: |
705/35 |
International
Class: |
G06F 17/60 20060101
G06F017/60 |
Claims
1. An automated transaction processing system for auditing
transactions between contracting parties on behalf of a plurality
of financial institutions, the system comprising: a central
processing node adapted, for different transactions involving
various financial institutions, to associate each transaction with
a unique one of the plurality of financial institutions, audit each
transaction according to a set of transaction rules defined as a
function of the unique financial institution and a business
relationship between the unique financial institution and at least
one of the contracting parties, and facilitate payment for each
transaction as a function of the audit.
2. The system of claim 1, wherein the central processing node is
adapted to associate each transaction with a first unique financial
institution associated with one of the contracting parties and with
a second unique financial institution associated with another one
of the contracting parties, and to audit each transaction according
to sets of transaction rules defined as a function of each of the
unique financial institutions and respective business relationships
between each unique financial institution and the respective
contracting parties.
3. The system of claim 1, wherein the central processing node is
adapted to audit transactions according to third party
information.
4. The system of claim 1, wherein the central processing node
includes a fee engine adapted for applying a fee to each audited
transaction and to assess the fee as a function of the business
relationship between the unique financial institution and at least
one of the contracting parties for the audited transaction.
5. The system of claim 1, wherein the central processing node
includes a rating engine configured and arranged to assign an
interest rate to a transaction between contracting parties, the
rate being implemented for extending credit on behalf of one of the
contracting parties.
6. The system of claim 5, wherein the central processing node is
further adapted to maintain a credit account for transaction
parties and wherein the rate is implemented in extending credit via
the credit account.
7. The system of claim 1, wherein the central processing node is
adapted to audit transactions between contracting parties according
to different sets of transaction rules by implementing the
transaction rules to determine a condition of validity of the
transaction.
8. The system of claim 7, wherein the central processing node is
adapted to audit transactions between contracting parties according
to different sets of transaction rules by implementing the
transaction rules to authorize payment for a valid transaction.
9. An automated transaction processing system and network for
processing transactions for buyers and sellers sponsored into the
processing network by a sponsoring bank, the system comprising: an
association processor configured and arranged, for each of a
plurality of transactions involving a buyer and a seller, to
identify a particular sponsoring bank for each buyer and seller as
a function of stored identifiers, the association identifying
respective business rules, set in accordance with the particular
sponsoring bank and the particular buyer or seller for which the
rules are set, for respectively processing transactions on behalf
of the buyer and on behalf of the seller for a particular
transaction; and a collaborative contracts processor configured and
arranged, for each particular transaction involving a buyer and a
seller, to use the identified business rules and a business
agreement between the buyer and seller to determine the amount of
fees that should be charged to the seller, should charged to the
buyer as a function of the identity of the buyer and the identity
of the buyer's sponsoring bank, the seller's sponsoring bank owes
the buyer's sponsoring bank, the buyer's sponsoring bank owes the
seller's sponsoring bank, and the buyer's sponsoring bank and the
seller's sponsoring bank owe the automated transaction processing
system and network.
10. The automated transaction processing system and network of
claim 9, further comprising a settlement processor configured and
arranged, for each particular transaction involving a buyer and a
seller, to: perform inter-bank settlement by calculating the amount
of funds to be collected from the buyer's sponsoring bank and
remitted to the seller's sponsoring bank to fund a payment that the
seller's sponsoring bank will make to the seller for all
transactions that achieve payable status within a payment period
defined as a function of the business rules.
11. The automated transaction processing system and network of
claim 10, wherein the settlement processor is configured and
arranged, for each particular transaction involving a buyer and a
seller, to: submit an electronic payment demand at a defined period
to the buyer's sponsoring bank for all net monies due to at least
one of the transaction processing system and the seller's
sponsoring bank, when the buyer's sponsoring bank is in a net funds
due to processor position; submit an electronic payment demand at a
defined period to the seller's sponsoring bank for all net monies
due to at least one of the transaction processing system and the
buyer's sponsoring bank, when the seller's sponsoring bank is in a
net funds due to processor position; submit an electronic payment
notice at a defined period to the buyer's sponsoring bank for all
net monies due the buyer's sponsoring bank after subtraction of
funds due to at least one of the transaction processing system and
the seller's sponsoring bank, when the buyer's sponsoring bank is
in a net funds due to processor position; and submit an electronic
payment demand at a defined payment period to the seller's
sponsoring bank for all net monies due to the seller's sponsoring
bank after subtraction of funds due to at least one of the
transaction processing system and the buyer's sponsoring bank, when
the seller's sponsoring bank is in a net funds due to processor
position.
12. The automated transaction processing system and network of
claim 9, further comprising a data access controller configured and
arranged, for each sponsoring financial institution, to: provide
access to transactions naming a buyer or seller organization
sponsored by the sponsoring financial institution; and maintain an
overview of their net position with each of their customers to whom
they are issuing credit, the overview showing each customer's net
position between payments due from the customer and payments due to
suppliers through the transaction processing system.
13. The automated transaction processing system and network of
claim 12, wherein the data access controller is further configured
and arranged, for each sponsoring financial institution, to perform
customer service functions related to transaction processing for
their customers within the transaction processing system, the
customer service functions defined in the sponsoring financial
institution's business rules in association with each customer.
14. The automated transaction processing system and network of
claim 9, wherein the collaborative contracts processor is
configured and arranged to implement profiles for each sponsoring
financial institution for specifying bank-specific operating
characteristics to use in processing transactions involving the
sponsoring financial institution.
15. The automated transaction processing system and network of
claim 14, wherein the collaborative contracts processor is
configured and arranged to perform a currency conversion using a
financial institution to process the currency conversion as
specified in the profile for a particular sponsoring financial
institution.
16. The automated transaction processing system and network of
claim 15, wherein the collaborative contracts processor is
configured and arranged to assess a markup fee to a sponsored user
as a function of profiles for the particular sponsoring financial
institution's profile.
17. The automated transaction processing system and network of
claim 14, wherein the collaborative contracts processor is
configured and arranged to use information in the profiles to
identify a financial institution to use for remittance collection
from buyers sponsored by the sponsoring financial institution.
18. The automated transaction processing system and network of
claim 14, wherein the collaborative contracts processor is
configured and arranged to use information in the profiles to
identify a financial institution that the sponsoring financial
institution specifies to use for payments to each seller sponsored
by the sponsoring financial institution.
19. The automated transaction processing system of claim 18,
wherein the collaborative contracts processor is configured and
arranged to use information in the profiles to identify a financial
institution that the sponsoring financial institution wants to use
for payments to each seller sponsored by the sponsoring financial
institution, as a function of a geographical location of each
seller.
20. The automated transaction processing system and network of
claim 14, wherein the collaborative contracts processor is
configured and arranged to use information in the profiles to
identify a location to which credit drawdown advice is to be
delivered and to specify the content of the credit drawdown
advice
21. The automated transaction processing system and network of
claim 9, further comprising a data storage arrangement configured
and arranged for storing all transaction data for transactions
involving sponsored buyers and sellers, and to provide access to
all of the transaction data to the collaborative contracts
processor.
22. The automated transaction processing system and network of
claim 21, wherein the data storage arrangement includes at least
two different databanks connected via a network link.
23. The automated transaction processing system and network of
claim 9, wherein the association processor is configured and
arranged to identify a particular set of business rules to
implement for a particular transaction as a function of a credit
term associated with the particular transaction.
24. The automated transaction processing system and network of
claim 9, wherein the association processor is configured and
arranged to identify a particular set of business rules to
implement for a particular transaction as a function of the
geographic location of at least one party to the particular
transaction.
25. The automated transaction processing system and network of
claim 9, wherein the association processor is configured and
arranged to identify a particular set of business rules to
implement for a particular transaction as a function of historical
information associated with at least one party to the particular
transaction.
26. The automated transaction processing system and network of
claim 9, wherein the association processor is configured and
arranged to store and implement identifiers to identify a
particular sponsoring bank for each of the buyer and seller by
storing and implementing user profiles for each buyer and seller,
the user profiles specifying the identifiers that identify a
particular sponsoring bank for each buyer and seller.
27. The automated transaction processing system and network of
claim 26, wherein the association processor is configured and
arranged to store and implement user profiles, for each buyer and
seller, that specify a non-sponsoring financial institution that
the buyer or seller wishes to use with the transfer of funds for
transactions.
28. The automated transaction processing system and network of
claim 27, wherein the association processor is configured and
arranged to select a store and implement user profiles, for each
buyer and seller, that specify a non-sponsoring financial
institution as a function of at least one of: the amount of a
particular transaction, the type of a purchase associated with the
transaction, the location of a purchase associated with the
transaction, taxes on the transaction, the interest rate available
from the financial institution, and insurance for the
transaction.
29. The automated transaction processing system and network of
claim 9, wherein the collaborative contracts processor configured
and arranged, for each particular transaction, to use the
identified business rules to select ACH (automatic clearing house)
outbound payment & facilitation functions to implement for each
particular transaction.
30. A method for auditing transactions between contracting parties
on behalf of a plurality of financial institutions, the method
comprising: associating each transaction with a unique one of the
plurality of financial institutions; auditing each transaction
according to a set of transaction rules defined as a function of
the unique financial institution and a business relationship
between the unique financial institution and at least one of the
contracting parties, and facilitating payment for each transaction
as a function of the audit.
31. The method of claim 30, further comprising, for each
transaction, defining a set of transaction rules for a unique
financial institution associated with the transaction as a function
of the unique financial institution and a business relationship
between the unique financial institution and at least one of the
contracting parties.
32. A system for auditing transactions between contracting parties
on behalf of a plurality of financial institutions, the system
comprising: means for associating each transaction with a unique
one of the plurality of financial institutions; means for auditing
each transaction according to a set of transaction rules defined as
a function of the unique financial institution and a business
relationship between the unique financial institution and at least
one of the contracting parties, and means for facilitating payment
for each transaction as a function of the audit.
33. A method for processing transactions for buyers and sellers
sponsored into a processing network by a sponsoring bank, the
method comprising: for each of a plurality of transactions
involving a buyer and a seller, identifying a particular sponsoring
bank for each buyer and seller as a function of stored identifiers,
the association identifying respective business rules, set in
accordance with the particular sponsoring bank and the particular
buyer or seller for which the rules are set, for respectively
processing transactions on behalf of the buyer and on behalf of the
seller for a particular transaction; and for each particular
transaction involving a buyer and a seller, use the identified
business rules and a business agreement between the buyer and
seller to determine the amount of fees that should be charged to
the seller, should charged to the buyer as a function of the
identity of the buyer and the identity of the buyer's sponsoring
bank, the seller's sponsoring bank owes the buyer's sponsoring
bank, the buyer's sponsoring bank owes the seller's sponsoring
bank, and the buyer's sponsoring bank and the seller's sponsoring
bank owe the automated transaction processing system and network.
Description
RELATED PATENT DOCUMENTS
[0001] This patent document claims priority under 35 U.S.C.
.sctn.119 to U.S. Provisional Patent Application No. 60/578,375,
entitled "Financial Transaction Processing System and Approach" and
filed on Jun. 9, 2004; this patent document is also a
continuation-in-part of U.S. patent application Ser. No. 10/437,405
(USBA.117PA), filed on May 12, 2003, to which benefit is claimed
under 35 U.S.C. .sctn.120 for common subject matter; U.S. patent
application Ser. No. 10/437,405 is a continuation-in-part of U.S.
patent application Ser. No. 09/259,657 (USBA.002C1), filed Feb. 26,
1999 now U.S. Pat. No. 6,571,149, which is a continuation of U.S.
patent application Ser. No. 08/748,243, filed on Nov. 12, 1996, now
U.S. Pat. No. 5,910,896; U.S. patent application Ser. No.
10/437,405 further claims priority under 35 U.S.C. .sctn.120 for
common subject matter to U.S. Provisional Patent Application Ser.
No. 60/379,561 (USBA.101P1) and filed on May 10, 2002.
FIELD OF THE INVENTION
[0002] The present invention is directed to communications and data
processing and, more specifically, to communications and data
processing involving transaction-related financial processing.
BACKGROUND
[0003] Operational management of contractual and transactional
interactions between buyers, sellers, financial institutions and
others involved in the exchange of products 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.
[0004] Financial institutions employ transaction processing
parameters that are unique to each institution. 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.
[0005] 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.
[0006] 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.
[0007] The above and other difficulties in the management and
coordination of financial transactions have presented
administrative and cost challenges to entities involved in various
aspects of transactions, including financial institutions and
others.
SUMMARY
[0008] 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.
[0009] According to an example embodiment of the present invention,
financial transactions involving financial institutions are managed
using an approach generally involving the use of rules for
processing payment-related aspects of the financial
transactions.
[0010] In a more particular example embodiment of the present
invention, a transaction management system is configured for using
sets of rules associated with financial institutions for processing
transactions. When transaction information is received, it is
associated with a particular sponsoring financial institution.
Rules for the sponsoring institution are used to process the
transaction. In some instances, the rules are further selected and
implemented as a function of one or more of the sponsored
transaction parties (e.g., a buyer or seller).
[0011] In another example embodiment of the present invention, an
automated transaction processing system is adapted for processing
transactions involving a plurality of financial institutions. The
system includes a central processing node adapted to audit (e.g.,
validate or otherwise approve) transactions between contracting
parties according to different sets of transaction rules. Each of
the respective sets of transaction rules are defined as a function
of a unique one of the plurality of financial institutions and a
relationship between the unique financial institution and at least
one of the contracting parties.
[0012] According to another example embodiment of the present
invention, an automated transaction processing system audits
transactions between contracting parties on behalf of a plurality
of financial institutions. The automated transaction processing
system includes a central processing node adapted, for different
transactions involving various financial institutions, to associate
each transaction with a unique one of the plurality of financial
institutions and to audit each associated transaction according to
a set of transaction rules. These transaction rules are defined as
a function of the unique financial institution and a business
relationship between the unique financial institution and at least
one of the contracting parties. In this regard, the audit involves
using information in the rules, upon which payment can be
authorized, and comparing or otherwise processing information for a
particular transaction (e.g., receipt of goods, issuance of an
invoice) to approve payment for the transaction (or deny payment
where transaction information fails to satisfy payment-type
conditions). The central processing node facilitates payment for
each transaction as a function of the audit.
[0013] 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.
BRIEF DESCRIPTION OF THE DRAWINGS
[0014] 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:
[0015] FIG. 1 shows a transaction processing arrangement, according
to an example embodiment of the present invention;
[0016] FIG. 2 shows an arrangement and approach for transaction
management, according to another example embodiment of the present
invention; and
[0017] FIG. 3 shows a flow diagram for transaction processing,
according to another example embodiment of the present
invention.
[0018] 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.
DETAILED DESCRIPTION
[0019] 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 financial institution rules and processes with
transactions, payments, tracking 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.
[0020] According to an example embodiment of the present invention,
a financial rules-based transaction approach is implemented with
multiple sponsoring financial institutions for automatically
processing financial transactions. The sponsoring financial
institutions sponsor transaction parties (e.g., buyers and
sellers); financial aspects of transactions between two or more of
the sponsored transaction parties are carried out as a function of
business rules for the financial institution sponsoring each
party.
[0021] In another example embodiment of the present invention, a
central transaction management system uses business rules (e.g.,
included in profile information) associated with financial
institutions to process financial transactions between parties
sponsored by the financial institutions. When the central
transaction management system receives transaction information, the
information is parsed for identifying characteristics that can be
associated with sponsoring financial institutions. When these
identifying characteristics match a particular financial
institution, the central transaction management system uses
business rules for the financial institution to process the
financial transaction. In addition, when identifying
characteristics for different parties to the transaction match
different financial institutions, financial aspects of the
transaction that are specific to each party are processed according
to the each party's corresponding sponsoring financial institution.
Funds relating to the financial transaction are thus transferred
according to the business rules associated with sponsoring
financial institutions for each party and to the particular
characteristics of the financial transaction.
[0022] In one implementation, the central transaction management
system audits data for transactions between the different parties
as a function of business rules for one or more of the transaction
parties. For example, where a particular party specifies
conditions, in its business rules, upon which payment can be
authorized, the central transaction management system implements
those conditions in connection with the audit and determines
therefrom a condition of payment for the transaction (e.g., whether
some or all of a particular invoice can be paid). As another
example, different parties to a contract may specify rules upon
which transaction data is to be audited to indicate that the
transaction is valid and/or ripe for payment. This auditing may
include, for example, setting a price for a particular transaction,
such as setting the price for a shipment involving bill of lading
(BOL) rating or setting the price for a transaction based on
characteristics of the transaction such as quantity of goods and/or
receipt of the goods. In another example, the auditing involves
comparing terms in transaction data from an electronic invoice to
previously agreed upon contract terms; where the invoice matches
the terms, or is within a tolerance where specified, the auditing
results in an approval (i.e., validation of the transaction) for
payment of the invoice. A multitude of such auditing approaches can
selectively be implemented, based on various terms set by different
transaction parties, by sponsoring financial institutions or other
related entities.
[0023] In another implementation, the central transaction
management system further uses business rules associated with
individual parties to a transaction in processing financial
transactions involving the individual parties. For instance, when
the central transaction management system receives transaction
information, the information is parsed (as discussed above) to
identify sponsoring financial institutions as well as the parties
to the transaction. The transaction is then process according to
the business rules of the sponsoring financial institutions as well
as the business rules of the parties to the transaction. These
party-specific business rules may be stored, for example, in a user
profile that is accessible by the central transaction management
system. The user profiles may include identifiers used to identify
buyer or seller transaction parties and/or sponsoring financial
institutions.
[0024] In some instances, the sponsoring financial institution for
a particular party is identified as a function of the identity of
the party and corresponding business rules for the party. For
example, when a party sets business rules to identify a particular
sponsoring financial institution, these business rules are
implemented in selecting the sponsoring financial institution.
Correspondingly, the business rules for the financial institution
identified by the party's business rules are used to process the
financial transaction.
[0025] In other instances, two or more financial institutions can
be specified by a particular party, including sponsoring and/or
non-sponsoring financial institutions. Business rules for the
particular party may include financial institution selection
criteria that is implemented as a function of the particular
transaction. For instance, selection criteria may be configured to
indicate that payment for transactions under a certain value be
processed (financed) using a first financial institution, while
payment for transactions at or over the certain value be processed
using a second financial institution. This approach may be
implemented, for example, where large value transactions that may
involve a longer payment period are desirably financed through a
financial institution offering terms that are practicable for
maintaining a longer payment term (i.e., lower rates). Small value
transactions typically involving a shorter (or no) payment term may
preferably be serviced using a financial institution offering
desirable services or low service fees, but higher rates.
[0026] Sponsoring financial institutions may implement criteria
similar to that discussed in the paragraph above for selecting a
particular institution via which to process transactions, with
selected criteria being implemented for making such selections.
This approach may be useful, for example, where parties to the
transaction agree to use a financial institution selected by the
sponsoring financial institution that sponsors the party into the
automated transaction process. In this regard, the financial
institution selected for providing payment for a particular
transaction is selectively different than the sponsoring financial
institution. Such a financial institution may be selected by the
sponsoring financial institution using, for example, a geographical
location of a seller to which payment is to be made.
[0027] In some implementations, the central transaction management
system works to keep separate the transaction rules for each
financial institution (and transaction parties, where appropriate).
Access to the transaction rules 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.
[0028] In some applications, a data access controller facilitates
the restriction of access to transaction information by providing
access to each financial institution for data relating to their
clients. The data access controller selectively facilitates access
via an overview type of data presentation that shows a financial
overview for each customer to whom the financial institution issues
credit. For example, for buyer customers, the data access
controller selectively implements an overview showing each buyer's
net position between payments due from the buyer and payments due
to sellers (suppliers) through the transaction processing
system.
[0029] In another application, the data access controller discussed
above is further configured and arranged, for each sponsoring
financial institution, to perform customer service functions
related to transaction processing for the financial institution's
customers within the transaction processing system. Such customer
service functions are defined in the sponsoring financial
institution's business rules in association with each customer. The
data access controller implements the business rules in performing
the customer service functions.
[0030] Business rules used by the central transaction management
system may be stored using one or more of a variety of approaches.
For example, a database accessible by the central transaction
management system and having labels or other identifying
characteristics that associate the business rules with a particular
financial institution 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.
[0031] The central transaction management system is further
configured to interface with financial institutions for a
particular transaction party, in addition to a sponsoring financial
institution for the transaction party. For instance, where a
transaction party has primary banking functions with a
non-sponsoring financial institution, the 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
financial transaction.
[0032] In some instances, the central transaction management system
interfaces directly with financial institutions 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 financial institution. Effectively, the
financial institutions use the central transaction management
system to execute transaction-processing functions that are carried
out using transaction-based rules specific to the particular
financial institution providing the transaction information.
[0033] 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 financial institution). 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 financial institution in some regards, relative to the
above discussion, to facilitate transactions in this manner.
[0034] According to another example embodiment of the present
invention, a central transaction management system uses transaction
information for buyers and sellers of products and/or services to
automatically derive pricing and/or payment options for individual
transactions. These products and services may include, for example,
tangible goods, shipment services, consulting services and
financial services (e.g., where the seller may be a financial
institution selling a financing package for a transaction between a
buyer and another seller). The transaction information may include,
for example, the identities of the buyer and seller, the products
and/or services being purchased, the date of the purchase and the
specific contract under the terms of which the transaction is being
executed. For instance, specific contracts under the terms of which
a transaction is being prosecuted may include prices agreed upon
between a buyer and seller for a particular product and/or
service.
[0035] Transaction-related contracts facilitated by the central
transaction management system may also (or in the alternative)
include rules agreed upon for setting certain financial and/or
price terms between a buyer and seller. In one instance, terms
associated with a particular transaction are automatically set by
the central transaction management system to correspond to
transaction information assigned to a particular buyer. The terms
may be set, for example, using predetermined terms agreed to by the
buyer and seller involved in the transaction. In another
implementation, pricing arrangements such as quantity discounts,
group discounts and conditional price variances (e.g., an
acceptable percentage of variance in cost associated with for
fluctuating shipping costs, product prices, financing costs and
others) are further automatically implemented in response to the
transaction information and the approved contract details in the
central transaction management system. In still another
implementation, financing terms such as processing fees for
facilitating a transaction, interest-related fees, credit-extension
fees and others are automatically set as a function of such a
transaction-related contract. Where credit is extended, a rating
engine is optionally implemented to assign an interest rate to an
applicable transaction, for extending credit on behalf of a
contracting party to the transaction.
[0036] Turning now to the figures, one or more of the
above-discussed approaches are selectively implemented in
connection with the processors and other functions shown in the
figures and discussed as follows. Beginning with FIG. 1, a
transaction processing arrangement 100 includes a central
transaction processor 110 programmed to automatically process
transaction information according to business rules corresponding
to particular financial institutions, according to another example
embodiment of the present invention. When transaction information
is received at the central transaction processor 110, the
information is associated with sponsoring financial institutions
for each party to the transaction and processed according to
business rules for the sponsoring financial institutions. The
central transaction processor 110 may be implemented, for example,
in connection with the above-discussed approaches including those
involving the discussion of a central transaction management system
and/or with a central transaction node in a network node-based
arrangement.
[0037] Business rules are supplied by a multitude of financial
institutions employing the central transaction node 110,
represented here by financial institution nodes 120 and 128. In
some instances, parties involved in transactions facilitated by the
central transaction node also supply business rules. The central
transaction processor 110 is in communication with a database 112
where transaction-related information including the above-discussed
financial institution rules is stored. The database 112 is
optionally coupled to (or part of) the central transaction
processor 110 and further may include a plurality of data storage
arrangements at different locations. The central transaction node
110 maintains separate (and secure) storage for these business
rules by restricting access to the rules by the financial
institutions (or others such as transaction parties).
[0038] The central transaction node 110 is further adapted to
communicate with a variety of different parties to a transaction,
represented by transaction parties 122, 124 and 126. These
transaction parties and the financial institutions represented by
user nodes 120, 122, 124, 126 and 128 are communicatively coupled
with the central transaction processor 110. The user nodes 120-128
may, for example, include one or more of a buyer, seller,
distributor, shipper, carrier, government agency, financial
institution or other type of individual, group or agency that would
be involved in a transaction, with parties shown in the figure by
way of example.
[0039] The nodes 120-128 interact with the central transaction
processor 110 for providing transaction-related information, such
as financial processing rules, accounting rules, orders, invoices,
shipping documents, payment authorization data, payment execution
data, customs documents, security documents and others. In
addition, this transaction-related information may include
information for relating the application of rules to transaction
data, such as payment processes, credit extension and finance
charges. In some instances, financial institution nodes provide
rules that are stored in the database 112, with other party nodes
simply interacting with the central transaction node 110 (e.g.,
without providing any information for storage in the database 112).
Transactions are thus processed as a function of stored rules for a
particular financial institution (or institutions) with which the
transactions are associated. In other instances, the database 112
is also implemented for maintaining transaction party-type
information, such as user preferences (e.g., reporting, billing,
credit extension) and financial institution preferences (e.g.,
which institution to use).
[0040] The transaction parties 122, 124 and 126 may be implemented
via sponsoring financial institutions, with nodes 122, 124 and 126
representing this combination of transaction parties with a
particular sponsoring financial institution. This combinatorial
representation may also maintain direct interaction between
transaction parties and the central transaction node 110 for
facilitating party-specific communications, such as for setting
business rules or profile information for individual parties.
[0041] In some implementations, one or more of the nodes 120-128
are used as interfaces to the central transaction processor 110,
with users at the nodes being able to provide transaction-related
information such as classification rules. In other implementations,
the central transaction processor 110 automatically accesses
information from the user nodes for a variety of purposes, such as
retrieving classification rules (e.g., accounting codes and/or
business rules) or updating related accounting fields. This
interaction between the nodes and the central transaction processor
110 is controlled using, for example, access authorization such as
those involving password-protected authorization and others.
[0042] When transaction data is received at the central transaction
node 110 for financial institution-type processing, the central
transaction node parses the data and automatically associates the
transaction data with a particular financial institution sponsoring
the transaction to which the data applies. This automatic
association is implemented using business rules in the database 112
and/or as a function of the node sending the transaction data. In
some instances, profile information for various sponsoring
financial institutions (and/or transaction parties) is stored in
the database 112 and used in connection with identifiers in
received transaction information to automatically associate the
transaction information with sponsoring financial institutions. The
central transaction node 110 processes the associated data
according to applicable business rules that may be tailored, for
example, to a particular type of transaction or to particular
transaction characteristics.
[0043] Where credit is extended on behalf of users, the central
transaction processor 110 selectively assigns an interest rate to
the extension of credit, either directly wherein an administrator
of the central transaction processor extends credit, or in
connection with an interest rate offered by a financial institution
extending the credit. In some applications, the central transaction
processor 110 implements a rating engine to assign an interest rate
to an applicable transaction, for extending credit on behalf of a
contracting party to the transaction. The rating engine uses
information about the contracting party in order to establish such
an interest rate.
[0044] In another example embodiment, the central transaction
processor 110 is further adapted to grant and control information
exchange with the database 112 as a function of inputs received
from the nodes 120-128, such as authorization inputs and
transaction-specific inputs. When users at one of the nodes 120-128
attempt to send information to or retrieve information from the
central transaction processor 110, authorization information from
the users is used to control the information transfer. The
authorization information may include, for example, access-type
information (e.g., a password or user ID) or simply document
information that the central transaction processor 110
recognizes.
[0045] In another example embodiment, the central transaction
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.
[0046] The user profiles and/or business rules discussed herein in
connection with FIG. 1 above and otherwise may include a variety of
information for use in transaction management and financial
processing. For instance, in addition to the above-discussed
approaches, a typical such profile may include one or more of the
following data: general ledger charts of accounts, identification
of computer systems submitting contract or transaction data,
customer lists, vendor lists, financial institution lists, contract
and price approval policies, transactional approval policies,
business rules, operational roles (e.g., defining what functions a
user associated with that role can perform), organizational
hierarchy (e.g., defining how much of a company's data a user
associated with a particular organizational node can access), and
individual users. Financial institution profiles may also include
information further defining the business relationship with
selected customers or other financial institutions and financial
processing organizations from the financial institution's
perspective.
[0047] FIG. 2 shows an arrangement and approach for transaction
management in an automated transaction network, according to
another example embodiment of the present invention. A transaction
processing system 210 interfaces with a plurality of financial
institutions for facilitating transactions, using data stored in a
database 220 for implementing rules for the transactions. These
rules are used to process financial aspects of the transactions,
relative to information received via sponsoring financial
institutions.
[0048] Two sponsoring financial institutions (230 and 240) are
shown, with multiple such institutions being contemplated but not
shown for brevity. Each sponsoring financial institution 230 and
240 works with multiple users, represented as users 1-N for
institution 230, and users A-i for institution 240. Communications
between the sponsoring financial institutions and the transaction
processing system 210, as shown by communication links, may be
implemented directly from the sponsoring financial institutions. In
addition, the shown communication links may represent a direct
communication from a sponsored user, the user including in the
communication sufficient information (and security type
information, where appropriate) to designate the appropriate
sponsoring financial institution.
[0049] The transaction processing system 210 also interfaces with a
variety of funds processing originators. By way of example,
automatic clearing house (ACH) originators 250 and 270, and SWIFT
(a European-based, straight through processing (STP) transaction
system) originators 260 and 280 are shown. These funds processing
originators are typically implemented as financial institutions
having appropriate funds processing capabilities for implementing,
for example, ACH or SWIFT-type functions. In this regard, the
transaction processing system 210 interfaces with financial
transaction processing entities for obtaining authorization to
proceed with a transaction and to coordinate fund transfer using
the respective originators (i.e., as conventional). The transaction
processing system's interface with ACH and other providers is
selectively specified by business rules used in processing a
particular transaction for payment and facilitation functions.
[0050] The business rules in database 220 typically include
user-specified rules that are provided by the financial
institutions using the transaction processing system 210 for
processing financial transactions. For example, user profile
information for each sponsoring financial institution can be stored
in the database 220 for use by the transaction processing system
210. This profile information may include, for example, business
rules specifying one or more various conditions or approaches
related to financial transaction processing, as discussed herein.
For more information regarding transaction processing in general,
and for specific information regarding the use of user profiles and
business rules for transactions, as well as computer and processing
arrangements and systems for use with the same (and as may be
implemented in connection with one or more example embodiments
herein), reference may be made to U.S. patent application Ser. No.
10/436,878 (USBA.101PA), entitled "Automated Transaction Processing
System and Approach" and filed May 12, 2003, and to U.S. Pat. No.
5,910,896 (USBA.002PA) filed Nov. 12, 1996, all of which are
incorporated herein by reference.
[0051] When the transaction processing system 210 receives
transaction data identifying a particular sponsoring financial
institution, the database 220 is accessed to retrieve profile
information (and corresponding business rules) for processing the
transaction data. The business rules are used to determine a
variety of transaction-related characteristics, such as fees to be
charged for different parties to the transaction, including buyer,
seller and their respective financial institutions. Additional
rules-based processing examples are discussed further below.
[0052] The storage of information in the database 220 may involve
the use of a single database, or may involve multiple databases,
either in a single or at multiple locations, communicatively
coupled with the transaction management system 210. In one
implementation, all transaction data for all buyers and sellers
sponsored by all financial institutions is stored in one
centralized database. The transaction management system 210 manages
the centralized database such that information in the database that
has a common relationship with other information in the database
can be cross-referenced and updated. For instance, where
information for a buyer and seller for a single transaction is
stored in the centralized database, updates made to the buyer's
information can be appropriately made to similar seller's
information. This approach can be implemented to ensure that any
buyer and any seller can do business with each other and see
up-to-date status and documents without latencies typically
involved attempting to replicate and synchronize data across
multiple databases.
[0053] Business rules stored in the database 220 are optionally
tailored to particular users that are being sponsored by the
financial institution. In this regard, the business rules
pertaining to a particular sponsoring financial institution, as
well as the user being sponsored for a particular transaction, are
retrieved from the database 220 and used accordingly. In some
instances, sponsored users also store profile information in the
database 220, such as preferred banking institution (i.e., with the
sponsoring financial institution simply sponsoring the transaction
for a fee and not funding the transaction).
[0054] In some instances, the transaction processing system 210
includes two or more system implementations, represented by system
implementations 1 and 2-N. These system implementations may involve
virtually separate implementations at a single location to
facilitate data security and continuity for particular sponsoring
financial institutions. For instance, each system implementation
may be implemented for a particular financial institution, with
communication between each system implementation and other system
implementations being facilitated within the transaction processing
system 210. In this regard, each user (sponsoring financial
institution) may tailor it's specific system implementation to its
own needs.
[0055] The system implementations with transaction processing
system 210 may also be implemented at physically separate
locations, with virtual ties to the transaction processing system
210. For example, the implementation of various aspects of the
transaction processing system may be appropriate for applications
in different countries or for point-of-use type applications (e.g.,
to reduce long distance data communications). This physically
separate approach may also be implemented, for example, to address
laws associated with transactions, including taxation and other
processing rules.
[0056] As discussed above, various business rules stored at the
database 220 are implemented by the transaction processing system
210 for a variety of transaction characteristics. One such
characteristic involves the determination of fees to be charged to
users (buyers and sellers), to sponsoring financial institutions
and, where applicable, to other financial institutions involved in
the transaction. In this regard, the database 220 stores business
rules characterizing these fees, and the transaction processing
system 210 uses these characterizing business rules to process
financial transactions. In addition, the database 220 may store
party-identifying information for use by the fee-based rules in
characterizing the fees to be assessed for a particular
transaction.
[0057] In some applications, the business rules are implemented to
arrive at a collaborative transaction term, such as a price or
other term automatically implemented as an agreed-upon term by
using previously agreed-upon business rules for generating such a
term. Fee-based rules implemented in connection with these
approaches may involve, for example, information for determining
the amount of fees to assess for one or more of the following:
[0058] fees to be charged to the seller for the transaction based
on the identity of the seller and the identity of the seller's
sponsoring bank;
[0059] fees to be charged to the buyer for this transaction based
on the identity of the buyer and the identity of the buyer's
sponsoring bank;
[0060] fees the seller's sponsoring bank owes the buyer's
sponsoring bank for this transaction;
[0061] fees the buyer's sponsoring bank owes the seller's
sponsoring bank for this transaction; and
[0062] fees the buyer's sponsoring bank and the seller's sponsoring
bank owe the transaction processing system 210 for this
transaction.
[0063] These collaborative type terms and approaches for
implementing the same are selectively carried out using, for
example, the transaction processing arrangement 100 shown in FIG. 1
and/or the transaction processing system 210 shown in FIG. 2, with
transactions involving buyers and sellers sponsored into the
processing network by a sponsoring bank. In these approaches, for
each of a plurality of transactions involving a buyer and a seller,
an association processor 212 identifies a particular sponsoring
bank for each buyer and seller as a function of stored identifiers.
The association identifies respective business rules, set in
accordance with the particular sponsoring bank and the particular
buyer or seller for which the rules are set, for respectively
processing transactions on behalf of the buyer and on behalf of the
seller for a particular transaction. These and other association
processor 212 functions can be implemented separately from or in
connection with (e.g., as a software-implemented function) the
transaction processing system 210.
[0064] In some applications, the association processor facilitates
the identification of business rules using a geographic location of
a party to the transaction, for example where transaction payment
characteristics are affected by such a location (e.g., where
tariffs and/or taxes are involved).
[0065] In other applications, the association processor identifies
business rules for a sponsoring financial institution using
historical information for a particular transaction party. For
example, where a financial institution implements different sets of
business rules based on payment characteristics, credit rating,
business volume or other historical-type information pertaining to
a transaction party, that information is used to select a set of
business rules to use in facilitating a transaction involving the
transaction party.
[0066] A collaborative contracts processor uses the identified
business rules and a business agreement between the buyer and
seller to determine the amount of fees assessed in accordance with
one or more of the above fees discussed in connection with the
fee-based rules. Other approaches involving a collaborative
contracts approach are discussed further below.
[0067] Turning back to FIG. 2 and with approaches involving the
above assessed fees, the transaction processing system 210 uses
information in profiles for facilitating the transfer of funds
from, or the extension of credit on behalf of, the entity to which
fees are assessed. For instance, where a particular fee is to be
assessed against sponsoring financial institution 230 and/or one of
the users 1-N, funds from that institution are provided directly
(e.g., funds transfer) or indirectly (e.g., extension of credit),
from the sponsoring financial institution 230 or from another
financial institution specified by the user, where applicable.
[0068] The user (e.g., buyer, seller and financial institution)
profiles discussed herein and implemented with collaborative-type
approaches may include a variety of information for use in
transaction management and otherwise. In some applications, typical
profiles include one or more of the following data: a general
ledger chart of accounts, identification of a computer system
authorized for submitting contract or transaction data, customer
and/or vendor lists, policies for contract, price or transactional
approval and business rules. Where individuals within an
organization participating in the collaborative-type approaches are
selectively authorized, operational roles for such users are
defined and include, e.g., access authorization for the users as
well as individual access tracking. Seller customer list profiles
may also include information further defining the business
relationship with the customer from the Seller's perspective, for
example, such as a retail buyer relationship or a wholesale buyer
relationship. List profiles for buyers who act as vendors (e.g., as
a seller or distributor) may also include information further
defining the business relationship with the vendor from the Buyer's
perspective.
[0069] In one particular implementation, profile information such
as business rules, operational roles, authorization levels and/or
other attributes are specific to particular levels and/or
individuals within a particular entity. This profile information is
stored for access by the transaction processing system 210 and used
for implementing transactions. For example, when a particular
financial institution or sponsored user includes different
subsidiaries, divisions or locations, profile information can be
tailored for the particular source. Certain profile information can
also be implemented to supersede other profile information, for
example, when a particular subsidiary is assigned different
specific pricing terms, relevant to another subsidiary of a common
entity.
[0070] In another example embodiment facilitating collaborative
approaches, the transaction processing system 210 stores
information for transaction parties including one or more of
financial institutions and sponsored users (e.g., buyers and
sellers), and communicates therewith using an identification
approach for users at the buyer and/or seller level. The
transaction processing system 210 controls access to the stored
information as a function of user identification (ID), with access
parameters controlled for processes such as contract modification,
price modification, display configuration, access to the stored
information for that particular user and others.
[0071] As an example using seller offerings that make up at least
part of the stored information for a particular seller as well as
buyer access controls, the seller offerings are automatically
configured for usage by the individual users. In this context,
seller offerings may involve real goods and/or services, as well as
or in the alternative to financial offerings, such as the extension
of credit and/or financial processing services. The automatic
configuration may, for example, include price, delivery and payment
options. In response to the seller offerings and other stored
information, the transaction processing system 210 is adapted for
accepting requests from buyers and communicating the requests to
the seller. The transaction processing system 210 is further
adapted for accepting acknowledgment of receipt by the buyer either
manually (e.g., an individual buyer logs into the system with a
user ID and confirms receipt) or electronically (e.g., buyer's
inventory receiving systems automatically generate and transmit a
detailed notice of receipt or acceptance). Once receipt or
acceptance is acknowledged, the system communicates that
acknowledgment to the seller. In one implementation, the system is
further adapted for automatically paying the seller in response to
the receipt/acceptance acknowledgment. In another implementation,
the system is further adapted to invoice the buyer for the
offerings. Further, "payment" in this context may involve the
drawdown of a credit line, or extension of credit in manners as
appropriate for the particular transaction.
[0072] In some applications, the transaction processing system 210
implements a settlement processor 214 in connection with
facilitating payment for a particular transaction between a buyer
and a seller. The settlement processor 212 performs inter-bank
settlement by calculating the amount of funds to be collected from
a sponsoring bank for the buyer and remitted to a sponsoring bank
for the seller. The settlement is used to fund a payment that the
seller's sponsoring bank will make to the seller for all
transactions that achieve payable status, e.g., within a payment
period defined as a function of the business rules.
[0073] The settlement processor 214 is implemented to facilitate
payment/settlement in a variety of manners, depending upon the
application and appropriate contract terms and other information
relative to the truncation parties and/or sponsoring financial
institutions involved in a particular transaction. In this regard,
some applications involve one or more of the following electronic
payment approaches as facilitated by the settlement processor 214
for a transaction involving a buyer and a seller, with sponsoring
banks for each. In one approach, the settlement processor 214
facilitates the submission of an electronic payment demand at a
defined period to the buyer's sponsoring bank for all net monies
due to at least one of the transaction processing system and the
seller's sponsoring bank, when the buyer's sponsoring bank is in a
net funds due (to the transaction processing system) position. In
another approach, the settlement processor 214 facilitates the
submission of an electronic payment demand at a defined period to
the seller's sponsoring bank for all net monies due to at least one
of the transaction processing system and the buyer's sponsoring
bank, when the seller's sponsoring bank is in a net funds due
position. In another approach, the settlement processor 214
facilitates the submission of an electronic payment notice at a
defined period to the buyer's sponsoring bank for all net monies
due to the buyer's sponsoring bank, after subtraction of funds due
to at least one of the transaction processing system and the
seller's sponsoring bank, when the buyer's sponsoring bank is in a
net funds due to processor position. In still another approach, the
settlement processor 214 facilitates the submission of an
electronic payment demand at a defined payment period to the
seller's sponsoring bank for all net monies due to the seller's
sponsoring bank after subtraction of funds due to at least one of
the transaction processing system and the buyer's sponsoring bank,
when the seller's sponsoring bank is in a net funds due to
processor position. In each of the above approaches, the net funds
due to processor position selectively characterizes funds due, and
in certain applications, characterizes funds due to an
administrator of the transaction processing system 210 for
transaction payment (e.g., from a buyer to a seller) and/or for
fees associated with the processing of the transaction payment.
[0074] In another implementation, the transaction management system
discussed in the preceding paragraph is further adapted for
accepting a receipt of purchase acknowledgment including receipt
characteristics. For example, characteristics such as total
acceptance of goods, partial acceptance of goods and rejection of
goods at the invoice or receipt line item level can be included in
the acknowledgment. These characteristics are tied to transaction
levels involving users sponsored by the financial institutions
(e.g., 230 or 240, shown by way of example). Where compliance
before payment for a transaction is executed is to be ensured, this
information is required to be verified a priori. An invoice or
invoices for a particular transaction are updated with this and
other transaction-fulfillment-related information. Using this
approach, problems with received purchases, such as damaged goods,
improper goods and improper financial terms are readily addressed.
The various invoicing and payment-related characteristics are
correspondingly modified (e.g., payment is only made for accepted
portions of goods, or credit for the cost of returning goods is
granted, or payment is made using only accepted terms such as those
relating to an accepted credit-related interest rate).
[0075] In a more particular example embodiment, financial
institutions approve financial contracts using a collaborative
contract manager and submit order and invoice quantities for
executing the contracts to the transaction processing system 210
(e.g., implementing a collaborative contract manager). The
transaction processing system 210 then uses the terms from the
collaborative contracts manager to establish financial processing
terms (e.g., credit rate or other cost) between a user of financial
services and the corresponding financial service provider. In one
instance, financial service providers use the collaborative
contracts manager as the central repository called by various
provider systems. In another instance, the financial service user
implements the collaborative contracts manager as the central
repository called by various procurement systems.
[0076] For general information regarding the implementation of
transaction functions and for specific information regarding
collaborative-type functions that can be implemented in connection
with one or more example embodiments discussed herein, reference
may be made to U.S. patent application Ser. Nos. 10/436,878
(USBA.101PA) and 10/437,405 (USBA.117PA), both filed on May 12,
2003 and fully incorporated herein by reference.
[0077] In another embodiment, the transaction processing system 210
is configured for settling inter-bank 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
sponsoring bank and remitted to the seller's sponsoring bank. These
funds are used to fund the payment that the seller's sponsoring
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's.
[0078] 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.
[0079] In one example, an electronic payment demand is submitted on
an interval (e.g., at least daily) to the buyer's sponsoring bank
for all net monies due either to the transaction processing system
or to the seller's sponsoring bank when the buyer's sponsoring bank
has net funds due. An electronic payment demand is also submitted
on an interval to the seller's sponsoring bank for all net monies
due either to the transaction processing system or to the buyer's
sponsoring bank when the seller's sponsoring bank has net finds
due. In addition, an electronic payment notice is submitted on an
interval (e.g., at least daily) to the buyer's sponsoring bank for
all net monies due to the buyer's sponsoring bank. The net monies
due are contemplated after subtraction of funds due to either the
transaction processing system or the seller's sponsoring bank when
the buyer's sponsoring bank has net funds due. An electronic
payment notice is also submitted to the seller's sponsoring bank
for all net monies due to the seller's sponsoring 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 sponsoring bank when the seller's sponsoring bank has net
funds due.
[0080] In connection with the various example embodiments discussed
in connection with FIG. 2 (and otherwise), a fee engine is
selectively implemented to facilitate the assessment of transaction
processing fees. In some applications, the fee engine is
implemented with a transaction processor (e.g., with transaction
processing system 210), as a software-implemented engine. In this
regard, fees such as those assessed in accordance with a business
relationship between a financial institution and a buyer or seller
party contracting therewith, or with a business relationship
between a financial institution and an administrative transaction
processor auditor, can be assessed using the fee engine. That is,
the fee engine applies a fee appropriate for each transaction, and
either directly or indirectly facilitates payment of that fee.
[0081] 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. These examples are
selectively implemented with a data access controller 216 and may
involve approaches discussed above in connection with similar data
access controller functions.
[0082] In one example embodiment, each buyer-sponsoring financial
institution and each seller-sponsoring institution has access to
the transactions naming their sponsored buyer or seller
organization. By enabling such access, each financial institution
is granted access to perform customer service functions related to
transaction processing for their customers within the transaction
processing system. These customer service functions may, for
example, include the provision of accounting-related data in an
appropriate format and at a selected interval, or include providing
a notification to the customer upon certain predefined events
related to transaction processing and/or financial status of
transactions or accounts. In addition, each financial institution
can maintain an overview of their net position with each of their
customers to whom they are issuing credit. The financial
institution is presented a view into the transaction processing
system that shows their customers' net position between payments
due from customer and payments due to suppliers (through the
transaction processing system).
[0083] In another embodiment, each buyer-sponsoring financial
institution has the capability, as enabled by user profiles stored
at the database 220, to specify a variety of bank-specific
operating characteristics. For example, each buyer-sponsoring
financial institution may specify the financial institution that is
to perform foreign currency translation on its sponsored buyer's
behalf. This approach may be implemented, for example, where the
seller desires to be paid in currency local to the seller and the
buyer desires to be billed in currency local to the buyer. Each
buyer-sponsoring financial institution may also specify a currency
translation markup amount to add to translation services being
provided to its buyers. The buyer-sponsoring financial institution
may also specify the financial institution to use for remittance
collection from its buyers. For general information regarding
transaction processing, and for specific currency conversion
implementations that may be implemented in connection with currency
conversion as discussed here in connection with FIG. 2, reference
may be made to U.S. patent application Ser. No. 11/104,394
(USBA.134PA), filed on Apr. 12, 2005 and entitled "Automated
Transaction Processing System and Approach with Currency
Conversion," which is fully incorporated herein by reference.
[0084] Seller-sponsoring institutions may also specify the
financial institution(s) to use for delivering payments to the
seller. For instance, one institution may be used for ACH
origination for sellers holding US-domiciled bank accounts and
another institution (e.g., a SWIFT institution) for European-based
sellers, and another for Latin American-based sellers.
[0085] Financial institutions issuing credit to either the buyer or
the seller can also specify where credit-related information is
retrieved from for use in the transaction. For example, the
location from which credit drawdown advice (e.g., relative to
available credit in an appropriate credit account) 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.
[0086] A variety of security-related functions are implemented with
the transaction management 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 sponsoring financial institutions (230, 240) are encrypted
using standard encryption technologies. Similarly, data flowing
from the transaction processing system 210 to sponsoring financial
institutions (230, 240) 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 the various system implementations 1, 2 and N are
employed at physically different locations, communication between
these system implementations and the transaction management system
210 is encrypted.
[0087] 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 management system 210 may
employ.
[0088] In some instances, the transaction processing system 210
addresses synchronization issues between various financial
institutions and organizations, such as those discussed above, by
implementing pricing and/or other transaction rules that have
previously been agreed upon such that disputes over transaction
price are typically eliminated. These rules may include, for
example, criterion defining pricing data that can be automatically
approved (e.g., transaction fees within a selected variance), and
also control pricing information made available to different users.
The pricing rules may also include, for example, prices associated
with particular transaction characteristics, with different prices
being assigned for particular transactions (e.g., such as with a
volume or amount discount).
[0089] In various other example embodiments of the present
invention, a credit-processing approach is implemented with a
transaction management arrangement, such as that shown in FIG. 2
and discussed above. For example, the transaction processing system
210 can facilitate the extension of credit on behalf of one or more
sponsoring financial institutions, or another financial
institution, in connection with a particular user participant in a
transaction.
[0090] In one such credit-processing implementation, a
buyer-sponsoring bank sponsors a buyer into the transaction
processing system 210 and network with an active connection to a
line of credit for usage within the transaction processing system
and network. The buyer creates trading partner relationships with
sellers who are sponsored into the transaction processing system
210, which facilitates the relationships and related transaction
processing. When a buyer makes a purchase from a seller, the buyer
sends an electronic copy of an order for the purchase to the
transaction processing system 210 and network. The seller fulfills
an order and issues an invoice electronically to the transaction
processing system 210.
[0091] Where particular events are to occur and/or conditions are
to be met before an invoice becomes payable, these events or
conditions are provided by an appropriate party to a transaction
(e.g., buyer, seller or third party (such as customs or a freight
forwarder)). These events and/or conditions can be specified using
business rules as discussed above, with the transaction processing
system 210 implementing the business rules.
[0092] The transaction processing system 210 uses business rules
and/or profiles for users to match incoming information such as
order, invoice, receipt and/or event notices. This incoming
information is audited and reconciled by the transaction processing
system 210 using appropriate business rules. For example, where a
buyer establishes profiles, the transaction processing system 210
implements those profiles to audit and reconcile the
information.
[0093] Where payment is ripe as determined, e.g., via an audit as
discussed above, and where payment is via the extension of credit,
the transaction processing system 210 verifies that the extension
of credit to the buyer and/or associated buyer party is
appropriate. Where the extension of credit is appropriate, the
transaction processing system 210 sends authorization to the
appropriate financial institution following rules established by
that financial institution via profiles within the transaction
processing system.
[0094] When authorization is received and all other conditions
required for payment are met, the transaction processing system and
network electronically funds a seller with a single payment across
all credit issuing institutions via a finds delivery pathway
specified in the seller-sponsoring financial institution's profile.
In some instances, the cost to the seller for this payment is
varied based on the financial institution supplying the credit. The
funds are delivered to the seller net of the seller-sponsoring
bank's fees to the seller (e.g., fees are withheld prior to
delivery of payment). The seller-sponsoring financial institution
uses the pricing capabilities of the transaction processing system
and network to compute and render the bill to the seller. Detailed
data supporting the payment continues to be resident in the
transaction processing system and network and does not add overhead
to the banking industries money movement networks.
[0095] In connection with the authorization above, the transaction
processing system 210 provides the buyer-sponsoring bank with a
data feed that enables it to update its credit line to the buyer to
acknowledge the draw down of that credit line to pay invoices. In
some instances, the buyer-sponsoring bank will also use the
transaction processing system 210 to calculate and render the
invoice to the bank's buyer customer, and facilitates the linking
of transaction data to the invoice. In these instances, the
buyer-sponsoring bank provides the transaction processing system
210 with information for processing the invoice accordingly, in
profile and/or business rule information.
[0096] FIG. 3 shows a flow diagram for transaction processing
involving the association of a particular financial institution
with a transaction, according to another example embodiment of the
present invention. At block 310, transaction data having financial
transaction identification information is received from a user
node. The financial transaction identification information may
include identification data that pertains, for example, to a
particular party to the transaction, to a financial institution or
to other identification information specific to the particular
transaction to which it applies. At block 320, the financial
transaction data is compared with financial institution
identification data. If no match between the financial transaction
data and a financial institution is found at block 330, a failure
notice is returned to a sender at block 335 indicating that the
transaction cannot be processed.
[0097] If a match between the financial transaction data and a
financial institution 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 financial institution 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 financial institution that is the
subject of the match (e.g., for specifying user preferences or
profiles as discussed above).
[0098] After the transaction processing data has been loaded, it is
used to audit the transaction data at block 350 for facilitating
financial aspects of the transaction. The audit generally involves
parsing the financial transaction data using loaded processing data
such as rules that can be implemented to specify whether the
financial transaction data indicates that payment can be made. For
instance, a price term engine can be used to derive a payment
amount for the financial transaction, using information in the
financial transaction data and in the loaded transaction data
(e.g., specifying pre-agreed contract terms used in arriving at a
price). Such a price term can be used for setting the price of one
or more aspects of the financial transaction data. The audit is
then used at block 360 to generate a payment term for the
transaction, and the payment term is used to facilitate payment for
the transaction. In this regard, the payment term may include one
or more of a payment amount, a time of payment, a credit term, a
method of payment or a source from where to draw the payment.
[0099] 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.
* * * * *