U.S. patent application number 12/493032 was filed with the patent office on 2009-10-22 for automated transaction processing system and approach with currency conversion.
This patent application is currently assigned to U.S. Bank National Association. Invention is credited to William H. Bailey, Dean W. Hahn-Carlson, James B. Pogue.
Application Number | 20090265274 12/493032 |
Document ID | / |
Family ID | 37084233 |
Filed Date | 2009-10-22 |
United States Patent
Application |
20090265274 |
Kind Code |
A1 |
Hahn-Carlson; Dean W. ; et
al. |
October 22, 2009 |
Automated Transaction Processing System and Approach with Currency
Conversion
Abstract
Transaction management for contract and contract-related
approaches is facilitated. According to an example embodiment of
the present invention, a transaction management system
automatically sets contract terms including currency conversion
terms for a transaction based on business rules previously
established between parties to a transaction. In one
implementation, the transaction management node automatically
derives a contract term including a pricing-related term for a
transaction between a buyer and seller using contract information
therefor. The pricing-related term is used to set a price for the
transaction, and a currency conversion term is used to convert the
set price (or a portion of the set price corresponding to a
particular transaction party) into a different currency.
Inventors: |
Hahn-Carlson; Dean W.;
(Lilydale, MN) ; Bailey; William H.; (Minnetonka,
MN) ; Pogue; James B.; (St. Paul, MN) |
Correspondence
Address: |
CRAWFORD MAUNU PLLC
1150 NORTHLAND DRIVE, SUITE 100
ST. PAUL
MN
55120
US
|
Assignee: |
U.S. Bank National
Association
|
Family ID: |
37084233 |
Appl. No.: |
12/493032 |
Filed: |
June 26, 2009 |
Related U.S. Patent Documents
|
|
|
|
|
|
Application
Number |
Filing Date |
Patent Number |
|
|
11104394 |
Apr 12, 2005 |
|
|
|
12493032 |
|
|
|
|
Current U.S.
Class: |
705/44 ;
705/39 |
Current CPC
Class: |
G06Q 40/00 20130101;
G06Q 40/04 20130101; G06Q 20/102 20130101; G06Q 30/06 20130101;
G06Q 30/04 20130101; G06Q 20/10 20130101; G06Q 20/40 20130101 |
Class at
Publication: |
705/44 ;
705/39 |
International
Class: |
G06Q 20/00 20060101
G06Q020/00 |
Claims
1. An automated transaction pricing and payment system comprising:
a rule-variable database that stores sets of predefined contract
variables specific to each of a plurality of established contracts
respectively agreed upon by parties including buyers and sellers,
and sets of business rule variables for the buyers and sellers, the
business rule variables including timing criteria and a predefined
standard for computing currency conversion data, the standard being
susceptible to fluctuation as a function of currency conversion
rates; a correlation database that stores correlation data for
correlating received transaction data sets with a set of predefined
contract variables and sets of business rule variables for a buyer
and a seller involved in a transaction to which the transaction
data set pertains; a transaction processing engine configured with
software to, for each received transaction data set for a
transaction involving a buyer and seller, use data in the
correlation database to correlate the received transaction data set
with contract variables and sets of business rule variables for the
buyer and seller, and execute a derivation algorithm, using the
correlated contract variables and business rule variables as inputs
to the algorithm, to derive a specific pricing term for the
transaction and to set a price for the transaction based upon the
specific term, the price being in a first currency; and a
pricing-settlement engine configured to respond to the derived
pricing term by, for each transaction, using the correlated
variables to select a currency conversion standard and time based
upon timing criteria and a predefined standard in the correlated
business rule variables, using the timing criteria and an active
currency conversion rate defined for the predefined standard,
convert the set price from the first currency into a converted
price in a second different currency, and generate and output
electronic payment instructions to effect payment and settlement
for the transaction based upon the set price, the business rule
variables and the converted price.
2. The system of claim 1, wherein transaction processing engine is
configured to execute a derivation algorithm by dynamically
selecting and implementing a derivation algorithm on a
transaction-by-transaction basis using the correlated business rule
variables for at least one party to the transaction.
3. The system of claim 1, wherein the transaction processing engine
is configured to execute a derivation algorithm by dynamically
selecting and implementing a derivation algorithm on a
transaction-by-transaction basis based upon currency conversion
criteria specified in the business rule variables for at least one
party to the transaction.
4. The system of claim 1, wherein the transaction processing engine
is configured to generate new pricing term derivation variables
specific to the transaction based upon correlated business rule
variables for buyer and seller parties to the transaction, and to
execute the derivation algorithm by using the generated derivation
variables as inputs.
5. The system of claim 1, wherein the transaction processing engine
is configured to generate new contract variables for the
transaction using correlated business rule variables for buyer and
seller parties to the transaction, and to execute the derivation
algorithm by using the new contract variables as inputs to the
algorithm.
6. The system of claim 1, wherein the pricing-settlement engine is
configured to generate new currency conversion variables using
correlated business rule variables, and to select the currency
conversion standard by using the generated currency conversion
variables to select the standard.
7. The system of claim 1, wherein the transaction processing engine
is configured to execute a derivation algorithm by using stored
contract pricing variables, previously agreed upon by the buyer and
the seller, as inputs to the algorithm.
8. The system of claim 1, wherein the transaction processing engine
is configured to match a product identification term in the
correlated business rule variables for the buyer with a seller
product specified in the transaction data set, and to execute a
derivation algorithm to derive a specific pricing term by using
correlated variables pertaining to the identified product as inputs
to the algorithm.
9. The system of claim 1, wherein the pricing-settlement engine is
configured to select a currency conversion standard based upon
correlated business rule variables that specify a timing
characteristic for determining a currency conversion rate.
10. The system of claim 1, wherein the pricing-settlement engine is
configured to use correlated business rule variables that specify a
reference location to set a date and time for determining a
currency conversion rate, and to convert the set price using a
currency conversion rate for the set date and time.
11. The system of claim 1, wherein the transaction processing
engine is configured to execute the derivation algorithm using
correlated contract variables defined for an established contract
between a financing entity providing funds to effect payment for
the transaction and one of a buyer and seller participant in the
transaction.
12. The system of claim 1, wherein the pricing-settlement engine is
configured to, for at least two transactions involving a currency
conversion between a first and second currency during a particular
time period, convert the set price from the first currency into a
converted price in a second different currency for each transaction
by converting a bulk sum of currency for set prices in each
transaction, processed using disparate derivation algorithm inputs,
from the first currency to the second currency based upon a
conversion configuration globally applied across the transactions,
and generate and output respective sets of electronic payment
instructions for each transaction to effect payment individually
for each party to each of the transactions.
13. The system of claim 1, wherein the pricing-settlement engine is
configured to assess a currency conversion fee to at least one
party to the transaction based upon the generated electronic
payment data.
14. The system of claim 1, wherein the pricing-settlement engine is
configured to convert the set price from the first currency into a
converted currency by converting funds relating to the set price
from the first currency to a second currency at a first currency
conversion rate and to convert funds relating to the set price for
at least one party to the transaction at a different currency
conversion rate.
15. The system of claim 1, wherein the pricing-settlement engine is
configured to select a currency conversion standard based upon
correlated business rule variables indicating an acceptable range
of currency exchange rates and external data indicating
currently-available exchange rates.
16. The system of claim 1, wherein the pricing-settlement engine is
further configured with software to compare an actual currency
conversion rate specified by the selected currency conversion
standard to a budgeted currency conversion rate specified in the
correlated business rule variables for a transaction party; in
response to the actual currency conversion rate being different
than the budgeted currency conversion rate, calculate a difference
between the converted set price using the actual currency
conversion rate and a set price as converted using the budgeted
currency conversion rate, and assess a fee to one of the
transaction parties based upon the calculated difference.
17. The system of claim 1, further including an auditing engine
configured to audit the payment for each transaction using the
correlated business rule variables and contract variables to
determine a condition of payment authorization for the transaction,
and wherein the pricing-settlement engine is configured to generate
and output electronic payment instructions in response to the
determined condition of payment authorization.
Description
RELATED PATENT DOCUMENTS
[0001] This patent document is a continuation of U.S. patent
application Ser. No. 11/104,394 and filed on Apr. 12, 2005, to
which benefit is claimed under 35 U.S.C. .sctn.120.
FIELD OF THE INVENTION
[0002] The present invention is directed to communications and data
processing and, more specifically, to communications and data
processing involving the processing of transactions involving two
or more currencies.
BACKGROUND
[0003] Operational management of contractual and transactional
interactions between buyers, sellers 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. The various parties involved in a transaction
typically change proposed terms and aspects of a proposed
transaction on a concurrent and/or iterative basis. In addition,
transaction aspects involving currency conversion rates and other
externally-influenced terms often fluctuate over time, relative to
events for a particular transaction. For example, from the time an
order is received to the time of performance of the order, currency
exchange rates often change.
[0004] Often, data representing each corporate participant's view
of the interaction is stored across one or more enterprise systems
managed by that particular corporate participant and not accessible
by other corporate participants. Consequently, it can be difficult
to know which draft document represents the most current
information about the interaction and whether the parties to the
transaction have a common understanding. Where the corporate
participants have communicated electronically (e.g. via email and
Internet-enhanced communications), these document-synchronization
difficulties have been compounded by an increased number of
co-existing draft documents being viewed by the parties. Commercial
transactions then become more difficult as business entities
attempt to perform transactions with each other, and in particular,
to perform payment related transactions involving currency
conversion.
[0005] A typical commercial interaction between a seller offering a
product and a buyer desiring to acquire that product moves through
multiple steps. First, the buyer and the seller negotiate an
agreement as to the price the buyer will pay. When this agreement
covers an extended period of time it is typically formalized in a
contract or catalog. Contracts and catalogs are typically
maintained by the seller in a seller-managed computer system that
is separate from the computer system or systems which the seller
uses to accept orders, fulfill orders and generate invoices. When
the invoice system used by the seller to bill the buyer has a
different price file than is resident in the seller-managed
contract system, pricing exceptions will occur which will increase
the cost of the interaction because buyer and seller personnel will
have to resolve the differences before a transaction can be
completed. The problem can be compounded when the buyer loads the
current contract prices into its procurement system for
determination of whether the seller is billing correctly during the
pre-payment order/invoice reconciliation process, and even further
compounded when the prices are dependent upon currency conversion
rates. All of the seller's invoicing systems could be representing
the current contract while one or more of the buyer's systems still
represent an expired or not yet active contract. Some or all of the
seller's invoicing systems could be representing expired or not yet
active contracts while all of the buyer's procurement systems are
up to date.
[0006] Where different currencies are involved for a particular
transaction, a currency conversion is typically made to convert
into a currency desired by a buyer, seller or other party to the
transaction. However, because currency conversion rates vary
greatly over time, it is often difficult to determine not only when
the conversion is to take place, but at what rate and at what cost
to which transaction party. In addition, different conversion rates
are available from different sources. Furthermore, where
pricing-related issues such as those discussed above occur, the
payment issues are further compounded with currency conversion
requirements associated with the pricing.
[0007] The number of combinations of events leading to transaction
misunderstandings and disagreements contributes significantly to
the overall cost of settling for the exchange of goods and/or
services that are the subject of a transaction. As a further
complication, the contract contents, the order, the invoice and
other documents representing the transaction and required to settle
the transaction often only exist in paper form for access to the
individuals attempting to resolve exceptions. Further, the data
that does exist electronically is often scattered across numerous
applications such as accounts payable, accounts receivable,
purchasing, accounting, buyer or seller group, shipping, and
receiving. Moreover, where each buyer transacts with many sellers
and each seller transacts with many buyers, tracking such drafts
becomes increasingly more difficult.
[0008] One type of transaction for which the above difficulties
apply is a shipping transaction. Traditional approaches have lead
to many challenges to managing transactions between one shipper and
one carrier. Typically, however, there are multiple carriers and
shippers involved in multiple transactions, which makes the
management process more complex, and that much more time-consuming
and inefficient. The process is labor intensive in that it relies
on physically matching the hard copy of a bill of lading (BOL) for
proof of delivery with the hard copy invoice and then trying to
apply the terms of a hard copy contract to calculate whether the
invoice amount is proper to pay. Exceptions need to be communicated
to the trading partner, often involving faxing or mailing paper
copies of support materials. Responses to requests for information
often results in more paper copies with hand-written annotations
that alter the understanding of how the transaction actually
transpired. The ensuing series of repetitive and time consuming
steps are a source of additional operational expense for both buyer
and seller. Also, each BOL is often rated multiple times by
multiple parties creating excessive redundancy.
[0009] Due to such difficulties and convoluted processes,
traditional shipment transaction management systems are highly
susceptible to billing errors and fraud. For example, there has
been no connection between the delivery of goods and when the
shipper is billed for delivery. This may result in double billing,
no billing at all, or overbilling the shipper for freight delivery
charges. Also, auditing errors may occur, which results in
incorrect billing or payment, which is exasperated when currency
conversion is involved. In addition, the carrier waits a
disproportionately long time for payment while the invoice is being
audited and/or disputed. For example, traditionally, a delivery
takes about five days whereas payment takes about forty-five days.
This delay adversely affects the carrier's working capital
resources which, in turn, raises the carrier's transaction cost and
raises the prices the carrier must charge to earn the economic
return required to remain in business. Where currency conversion is
involved, conversion rates vary over time and thus delays due to
auditing errors or delivery may result in a very different
conversion rate, if the conversion is carried out on a basis that
fluctuates with these delays.
[0010] Additional costs arise as a result of the existing
inefficiencies. Many of the costs are individually small, but very
large in the aggregate. For example, the carrier incurs
administrative costs including: the cost to create and deliver the
initial invoice, costs of resolving billing disputes, costs of
providing a signed copy of the BOL to the shipper, costs of posting
accounts receivable and the costs of absorbing price fluctuations
relative to currency conversion rates. The shipper incurs similar
administrative costs to receive the bill, match it with the BOL,
manually check the contracts to determine if pricing is correct,
generate and deliver payment to the carrier.
[0011] The complexity of modern transactions has also lead to
expensive administrative costs associated with the transactions.
Administrative costs include personnel, software, hardware, and
entire departments created for managing commercial transactions to
ensure accurate and timely billing and payment. These costs are
furthered when transactional aspects become more complex, such as
those involving fluctuating currency conversion rates. 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 and, in particular, with
fluctuating currency rates for those transactions involving
different currencies.
[0012] The above and other difficulties in the management and
coordination of transactions have presented administrative and cost
challenges to business entities on buyer and seller ends of
transactions, as well as those involved in other aspects of such
transactions.
SUMMARY
[0013] 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.
[0014] According to an example embodiment of the present invention,
a transaction processing approach involves automatically processing
transactions between transaction parties as a function of
transaction party rules and a currency conversion term.
[0015] According to another example embodiment of the present
invention, a transaction processing approach involves a transaction
processor implemented for automatically processing currency
exchange for a transaction involving contracting parties. The
transaction processor is adapted to access contract-related
business rules for the contracting parties and to automatically
convert currency for a transaction related price for one of the
contracting parties.
[0016] In one implementation, the transaction processor uses the
business rules to select a particular source for use in determining
a currency exchange rate to use in converting the currency. In
another implementation, the transaction processor uses business
rules to select a particular date and time to use in setting a
currency exchange rate to use in converting the currency
(implemented, e.g., where transaction parties are in different time
zones).
[0017] In another implementation, a data storage arrangement stores
the business rules used by the transaction processor. Transaction
parties store business rules that can be used in a plurality of
transactions. When the transaction processor receives transaction
information for processing, it identifies parties to the
transaction from the transaction information and accesses the
stored business rules for the identified parties. Using these
accessed business rules, the transaction processor automatically
selects (e.g., using an exchange rate reference authorized by the
business rules) an exchange rate and converts currency for the
transaction using the exchange rate.
[0018] 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
[0019] 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:
[0020] FIG. 1 shows an arrangement and approach for transaction
management, according to an example embodiment of the present
invention;
[0021] FIG. 2 shows a transaction processing arrangement, according
to another example embodiment of the present invention; and
[0022] FIG. 3 is a flow diagram showing an approach for transaction
management involving currency conversion, according to another
example embodiment of the present invention.
[0023] 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
[0024] 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 pricing (and related currency conversions) to
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.
[0025] According to an example embodiment of the present invention,
a transaction management arrangement uses transaction party (e.g.,
buyers and sellers) information to automatically derive pricing
and/or payment options with currency conversion for individual
transactions. The transaction information may include, for example,
the identities of transaction parties, goods or services of the
transaction, rules for processing currency conversions, user
profile information specific to a particular party or parties to
the transaction and others. When payment-related transaction
functions are carried out, the currency conversion information is
used to determine a payment amount for one or more of the
transaction parties.
[0026] The transaction information may be set out in specific
contracts between transaction parties or implemented using
previously-agreed upon or otherwise standard transaction practices.
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 item and/or transaction
rules agreed upon for setting certain prices between a buyer and
seller and for performing currency conversions. Conditional
contract terms may also be implemented to facilitate the selection
between one or more different contract terms, or to facilitate the
derivation of a new contract term.
[0027] Payment-related transaction functions as described above
typically involve actual payment (i.e., transfer of money) to a
seller on behalf of a buyer as well as settlement functions
involving funding and accounting. In some applications, settlement
functions involve the passage of information for accounting
purposes including the posting of payment against accounts
receivables. In addition, settlement functions involve, where
appropriate, collecting money relating to the payment directly
and/or via an indirect approach such as the drawdown of a credit
line (and related accounting).
[0028] Another example embodiment of the present invention is
directed to a processing system that automatically manages
transactions using a database implementation that provides a source
of product prices and contracts for a multitude of transactions and
transaction parties. In advance of any transaction, prospective
buyers and sellers negotiate and/or validate prices and contract
terms, or simply validate the electronic representation of prices
and contract terms negotiated through other means. For each
contract, a buyer reviews, accepts and/or disputes contract term(s)
or contract term updates. Once the buyer accepts a contract, a
processing center stores the accepted contract and activates the
contract for current and/or future transactions.
[0029] A collaborative contracts manager applies contract terms for
actual performance of the contract, with parties involved in the
transaction defining the applicable contract terms including
pricing and related currency conversion terms. In some instances,
parties to the transaction directly define contract terms by
agreeing to specific terms. In other instances, parties to the
transaction indirectly define contract terms by setting business
rules by which the party is willing to participate in transactions.
The collaborative contracts manager then uses these business rules
to set contract terms. These business rules may, for example, be
derived from and/or include buyer and/or seller profile information
that includes contract-related data such as product, pricing,
currency-conversion terms, shipping, payment terms, currency type,
customs information and other typical contract data. The business
rules may also include information that relates to a particular
type of transaction or generally accepted contract type terms, and
may not necessarily be specific to a particular transaction party
or a particular transaction. Furthermore, the business rules may be
implemented with tolerance information, such as tolerance payment
ranges, currency conversion rate tolerance, delivery term ranges
and other information for use in automatically negotiating or
otherwise setting contract terms. These business rules can be
stored in a database accessible to the collaborative contracts
manager. All pricing information and business rules are retrievable
by a transaction manager or by applications remote from the
collaborative contracts manager such as those located at buyer or
seller locations (with security controls for remote access).
[0030] In some instances, the collaborative contracts manager
automatically resolves (or attempts to resolve) transaction
disputes or incongruous contract terms. Predefined and accepted
business rules are used to automatically arrive at contract terms
prior to executing a transaction. In addition, where business rules
for different parties to a transaction call for different contract
terms, the collaborative contracts manager attempts to
automatically resolve the different terms using tolerances or other
information allowing variance from actual business rules. For
example, when used for currency conversion type applications, the
collaborative contracts manager sets conversion parameters such as
conversion rate and conversion timing based on specific contract
terms and/or business rules for each party to a transaction. When
the collaborative contracts manager is unable to automatically
resolve disputes or incongruous contract terms, the processing
system alerts parties involved in the unresolved transaction, who
can interact with the processing system to work towards
resolution.
[0031] The user profiles discussed herein may include a variety of
information for use in transaction management and otherwise. For
instance, a typical such profile includes one or more of the
following data: user identification information, business rules for
the user, general ledger charts of accounts (e.g., and accounts
receivable as posted against for payment processing as described
above), identification of computer systems submitting contract or
transaction data to the collaborative contracts manager, customer
lists, vendor lists, contract and price approval policies, currency
conversion policies, credit extension policies (e.g., for extending
a credit liability to a transaction party), payment policies,
transactional approval policies, 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 universe a user associated with a particular organizational
node can access), and users. 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 and/or a wholesale buyer relationship.
Buyer vendor (e.g., seller or distributor) list profiles may also
include information further defining the business relationship with
the vendor from the Buyer's perspective.
[0032] In another example embodiment of the present invention, an
electronic interface facilitates user access to a transaction
management system such as that involving a collaborative contracts
manager as discussed above. The electronic interface is adapted to
communicate with the transaction management system for implementing
a variety of processes, such as those involving the setting of
contract terms, selection of currency conversion information and
purchases of goods. The electronic interface also facilitates
user-executed search functions for accessing information such as
product information, product prices, currency information,
contracts and price notes. Access to information via the user
interface is adaptively controllable, for instance, using
authorization approaches including user identification, interface
identification, password access and others.
[0033] The approaches to the use of business rules as well as
contract information and user profiles (as part of business rules
or otherwise) as discussed herein may be implemented in a variety
of manners. One implementation involves a transaction management
approach that is based on business rules previously established by
buyer(s) and seller(s). The transaction management system includes
a computer and communications node adapted for deriving prices for
transactions as a function of pricing rules that are agreed upon by
buying and selling entities related to the transaction. These
pricing rules may be implemented via the business rules and/or may
be tailored to a specific transaction. For general information
regarding the use of business rules, and for specific information
regarding transaction processing approaches that may be implemented
in connection with one or more example embodiments discussed here,
reference may be made to U.S. patent application Ser. No.
10/436,878 (USBA.101PA), filed May 12, 2003, which is fully
incorporated herein by reference.
[0034] In another example embodiment of the present invention, an
automated pricing and payment system conducts transaction processes
for transaction parties who provide respective sets of business
rules with information for selecting a currency conversion
standard. Currency conversion standards that may be implemented
include, for example, public standards based upon published rates
or other relative values of different currency, with the standards
being susceptible to fluctuation as a function of currency
conversion rates. The system includes a transaction processor that
can be implemented, for example, using one or more of a variety of
processors or combinations of processors, such as a CPU or a
distributed processing arrangement with multiple processors that
communicate over a network.
[0035] The transaction processor is adapted to receive and use the
business rules to derive a specific term for a transaction to be
implemented by transaction parties, and sets a transaction price
(in a first currency) as a function of the specific term. The
specific term may be derived using, for example, information in a
contract between the transaction parties directly identifying a
fixed transaction price, or information that uses characteristics
of the transaction together with stored information to provide a
flexible transaction price. The transaction processor further
selects a currency conversion standard using the business rules,
and, using the selected standard, converts the set price from the
first currency into a second different currency for at least one
party to the transaction. Payment and settlement are then effected
for the transaction as a function of the set price, the business
rules and the converted set price. For instance, with a seller and
buyer who contract for goods, payment and settlement can be
effected by paying the seller in the first currency at the set
price, and by extracting funds from the buyer in the converted set
price. Further, fees associated with the currency conversion are
selectively assessed with the effecting of payment and settlement,
with a fee built into the selected currency conversion standard
and/or being assessed separately to one or both of the transaction
parties by the transaction processor.
[0036] FIG. 1 is a communication system 100 including a
collaborative contracts manager 110 for handling business
transactions between a seller and a buyer respectively at a seller
terminal 122 and a buyer terminal 120, according to another example
embodiment of the present invention. The seller terminal 122
includes a seller processor 123 adapted to generate a seller
profile, one or more authorized buyer profiles and contract data,
and further to communicate the profiles and contract data to a
seller interface 133. The seller interface 133 includes a data
processing device 146 adapted to establish rules for a business
transaction by submitting a seller profile, one or more authorized
buyer profiles and contract data (i.e., received from the seller
processor 123) to a processor 140. The seller interface 144 is
further adapted for displaying contract data received from the
processor 140, and communicating to the seller from the processor
140 the acceptance or dispute of contract data by a buyer. The
processor 140 electronically organizes a seller's contract data
using a seller's profile, with the contract data and profile being
stored in a data storage unit 142. The seller terminal 122
facilitates the control of access to the seller's contract data
stored in the data storage unit 142 using, for example,
authorization or password protection criteria.
[0037] The buyer terminal 120 includes a buyer processor 124
adapted for generating a buyer profile and communicating the
generated profile to a data processing device 134 at a buyer
interface 132. The buyer interface 132 is adapted for displaying
contract data received from the processor 140. The data processing
device 134 communicates a condition of acceptance of contract data
as input at the buyer interface 132 to the processor. The processor
140 is coupled to a collaborative contracts manager 110 that
provides an interface for buyer and seller transaction management
including pricing management. The processor 140 processes and
stores pertinent business transaction information in the data
storage unit 142, with access thereto being restricted to
authorized users (i.e., authorized buyers and sellers via buyer and
seller terminals).
[0038] One or both of the buyer and seller terminals 120 and 122 is
further adapted to provide currency conversion terms, which can be
stored at the data storage unit 142 (or, in the instance where a
contract is currently processed, used directly by the processor
140). Using the buyer and seller profiles, the collaborative
contracts manager 110 automatically sets prices for transactions
between the buyer and seller and, for at least one of the buyer and
seller, sets currency conversion parameters.
[0039] In one implementation, the processor 140 interfaces with a
payment system 141 including an issuing institution 144 and a
paying institution 152. An issuing processor 145 of the issuing
institution 144 maintains a credit account for the buyer terminal
120 and debits (extends liability to) a particular buyer terminal's
account for transactions managed with the communications system
100, such as the shipment cost of a product, the product cost and
others. In response to transactions managed at the processor 140, a
paying processor 154 of the paying institution 152 tenders payment
to the seller terminal 122, for example, when the receipt of goods
is acknowledged by a buyer or at the time a buyer makes a
purchase.
[0040] In another implementation, the system 100 includes or is
adapted to interface with one or more currency exchange functions,
represented by currency exchange function 160. The currency
exchange function 160 may be implemented via the processor 140,
which may perform a currency exchange (and assess associated fees,
or build the fees into the exchange rate). Rules for effecting
currency exchange, such as how to determine the currency exchange
rate (e.g., using a standard index) and others can be supplied by
buyer, seller or other transaction parties. The exchanged currency
value is used, where applicable, for communicating payment
information to the payment system 141.
[0041] In some applications, the currency exchange function is
implemented separately from the processor 140, which selects the
exchange function to execute the exchange, e.g., by selecting a
particular exchange company, by selecting a particular published
standard for the particular type of currencies being converted or
by selecting a standard among those available for the particular
conversion. This external exchange is implemented at a position in
the payment chain that is selected as a function of the
application. For instance, when the seller wishes to be paid in a
particular currency that requires a conversion, the processor 140
can direct the payment system 141 to use a particular source to
execute the currency exchange function 160. In other applications,
the payment system 141 performs the exchange.
[0042] In other applications involving an external exchange
function, the party or parties performing the exchange also
interact with the processor 140 and, in some instances, with the
collaborative contracts manager 110. Such an external party may
further implement user profiles and other information in a manner
similar to that discussed above and as can be implemented with
sellers or buyers via terminals 122 or 120, respectively. For
example, contract terms such as exchange rate terms can be set
using business rules related to the exchange rate, with the
collaborative contracts manager using business rules to arrive at
an acceptable exchange rate. The business rules used for setting an
exchange rate are chosen as a function of the parties carrying out
the exchange. For example, where a seller at seller terminal 122
requests to be paid in a particular currency, business rules for
that seller and the entity performing the exchange may be used to
set the exchange rate.
[0043] In various implementations, an entity managing the processor
140 may interact as an intermediary between a buying or selling
party and a currency exchange entity. Here, the buying or selling
parties arrive at a currency exchange agreement with the entity
managing the processor 140. In turn, the entity managing the
processor 140 may have a different agreement with a currency
exchange entity. In this regard, the buying or selling party
receive an exchange rate agreed upon via the processor 140, and the
managing entity running the processor executes the exchange at a
rate agreed upon with the currency exchange entity. In this regard,
the managing entity running the processor 140 may negotiate a
preferential exchange rate using its high volume (as generated by a
multitude of buying and selling parties), and charge the buying and
selling entities a less preferential exchange rate.
[0044] FIG. 2 shows a transaction processing arrangement 200
including a transaction processor 210 programmed to automatically
process currency conversion aspects of a transaction, according to
another example embodiment of the present invention. The
transaction processor 210 is in communication with a database 212
and an exchange rate assignment engine 214. The database 212 stores
transaction-related information including rules for currency
conversion, as well as auditing information for individual currency
conversions as applicable to one or more transactions. The currency
conversion engine 214 processes currency conversion related aspects
of a transaction using rules from the database 212 and at the
direction of the transaction processor 210. In various
implementations, the database 212 and/or the exchange rate
assignment engine 214 is implemented as part of the transaction
processor 210. In other implementations, one or both of the
database 212 and the exchange rate assignment engine 214 are
located at a remote location and/or include a plurality of circuits
at different locations.
[0045] A plurality of user nodes 220, 222, 224, 226 and 228 are
communicatively coupled with the transaction processor 210. The
user nodes 220-228 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. Referring to FIG. 1 as an
example, one or more of the seller terminal 122, buyer terminal
120, processor 140, payment system 141 or currency exchange entity
effecting the currency exchange function 160 may be implemented at
one of the user nodes 220-228.
[0046] In another implementation, the transaction processor 210 is
adapted to automatically apply currency rules for assigning
currency exchange rates or other parameters to a transaction when
new transaction information is received or executed. This new
transaction information may, e.g., be detailed in a transaction
document such as an order or invoice. The currency rules are used
by the exchange rate assignment engine 214 to assign the exchange
rate to the transaction or to a portion of the transaction to which
the exchange rate applies.
[0047] When an update to the currency rules is received at the
transaction processor 210 (e.g., via one of the user nodes
220-228), a new call to assign an exchange rate to a transaction is
made by the processor and corresponding updates are made. For
instance, when a transaction for a particular user has been
assigned a particular exchange rate parameter and that user inputs
an update to currency rules used to assign the exchange rate
parameter, the transaction processor 210 automatically updates the
parameter assigned to the transaction. Optionally, the user
providing the assignment rule update selectively controls the
application of the updated rules, for example where the user
desires to selectively apply the updated rules to new
transactions.
[0048] The user nodes 220-228 can interact with the transaction
processor 210 for providing a variety of different types of
transaction-related information. Such transaction information may
include, for example, currency exchange parameters, accounting
rules, orders, invoices, shipping documents, payment authorization,
payment execution, customs documents, security documents and
others.
[0049] The transaction processor 210 records, in the database 212,
currency-conversion related information to facilitate the auditing
of individual and/or group transactions involving currency
conversion. This information may include one or more of a variety
of types of information, with examples applicable to FIG. 2
including "pay to" currency type and amount, "bill to" currency
type and amount, conversion date/time and conversion rate. When
outside entities at nodes 220-228 (or others, such as a regulatory
entity) is allowed to access the database 212, audit information is
made readily available (e.g., for compliance with Sarbanes-Oxley
related rules).
[0050] The conversion date and rate are selectively applied to one
or both of the "pay to" and "bill to" portions of the transaction
as a function of the types of currencies and/or business rules
associated with parties to a particular transaction. Where a
transaction involves only one currency conversion (i.e., between a
billing and paying currency), the transaction processor 210
performs a currency conversion in connection with the transaction
portion relevant to the currency conversion.
[0051] The system 200 can be implemented using a multitude of nodes
and arrangements, and is applicable to a variety of transaction
processing approaches. However, for purposes of discussion, each of
the user nodes is implemented as follows in connection with a
particular transaction. Node 220 is a buyer node representing a
buyer in a transaction and node 222 is a seller node representing a
seller. Nodes 224, 226 and 228 respectively represent financial
institutions.
[0052] The buyer 220 and the seller 222 provide business rules that
are stored in the database 212 for use by the transaction processor
210. When a transaction initiating event such as a request for
goods and/or services by the buyer 220 occurs, the transaction
processor 210 retrieves and uses the business rules to derive a
term for use in setting a price for the transaction. For example,
where the buyer 220 and seller 222 store business rules indicating
a contractual relationship and information for setting a price, the
transaction processor 210 derives a price term, such as the price
per unit, for the transaction.
[0053] The transaction processor 210 receives transaction
initiating event data with a transaction data receiving function
230 and matches the event data with a particular user (e.g., the
buyer 220 and/or the seller 222) with a match function 231. Such
event data may include, for example, an order or an invoice
relating to a transaction between users. The matching may involve,
for example, matching the event data to a particular user or to a
particular transaction using a product identification term that is
associated with goods and/or services for the transaction. A rule
retrieval function 232 implements the matched user information to
retrieve business rules applicable to the transaction event from
the database 212 (e.g., by retrieving business rules tagged or
otherwise associated with the matched user information).
[0054] A pricing engine 233 uses the retrieved business rules to
set a price for the transaction in a first currency, for example,
by using contract price information in the business rules or by
calculating a price using terms in the business rules and other
characteristics of the transaction such as quantity, transportation
or regulatory issues. The pricing engine 233 uses information in
documents (e.g., the transaction initiating event data) to identify
those rules in the retrieved rules to use in setting the price.
Such information may include, for example, a contract identifier
that identifies a specific contract to which the information
applies, an item identifier that identifies an item for which the
price is being set, a currency code identifying the currency in
which the transaction is denominated quantity and order date. Using
these approaches, the price set via the pricing engine is the "pay
to" price for the seller 222 to be paid.
[0055] An exchange rate retrieval function 234 retrieves an
exchange rate using the business rules and the exchange rate
assignment engine 214. In some instances, the exchange rate
assignment engine 214 is functionally implemented with the exchange
rate retrieval function 234. The business rules may specify a
particular approach to assigning an exchange rate, such as by
identifying a particular conversion standard to use (e.g., a
published standard), or by identifying a conversion standard using
input received from one or more of the buyer and seller. After the
exchange rate has been set, an exchange pricing function 235 sets
the price for the transaction in a second currency. This price is
the "bill to" price that the buyer 220 will be billed for the
transaction.
[0056] The transfer of funds between the financial institutions
224, 226 and, in some instances, 228 is carried out in accordance
with the above approach. For example, where the financial
institutions 224 and 226 are respectively the buyer's and seller's
financial institutions, funds in the "bill to" amount are
transferred from the buyer's financial institution and funds in the
"pay to" amount are transferred to the seller's financial
institution. In some instances, the business rules in the database
212 indicate that one of the buyer's and seller's financial
institutions will carry out a currency conversion. In other
instances, the business rules specify that a third financial
institution 228 carry out the currency conversion.
[0057] In some applications, the transaction processor 210 further
carries out settlement functions for transactions, including, e.g.,
functions relating to accounting and payment functions. In one
accounting function example, when the seller 222 is paid on behalf
of the buyer 220 (with appropriate currency conversion
characteristics), the transaction processor 210 automatically posts
the payment against an accounts receivable record for the seller
222 (e.g., stored in the database 212, at the seller 222 or
elsewhere). In a payment function example, the transaction
processor 210 selects a funding source for paying the seller 222
and, accordingly, carries out payment settlement functions for
extracting funds from the buyer 220. These funds may be extracted
directly (e.g., from the buyer's financial institution 224) or
indirectly via a credit extension approach, such as by drawing down
a credit line for the buyer. In some applications, funds are
extracted directly and accordingly provided directly to the seller
222. In other applications, funds are provided to the seller 222 on
behalf of the buyer 220, with the payment settlement function being
subsequently carried out for retrieving funds from the buyer to
cover the payment for the seller (and, e.g., to cover processing
and/or conversion fees).
[0058] In some implementations, the transaction processor 210
carries out the currency conversion using, for example, the third
financial institution 228. Funds associated with the "bill to"
amount received from the buyer's financial institution 224 are
transferred to third financial institution 228, and funds in the
"pay to" amount are transferred from the same (or another)
financial institution and transferred to the seller's financial
institution 226.
[0059] While a variety of currency conversion related payment
functions can be implemented with the transaction processor 210,
with a few examples of these functions discussed above, the
transaction processor records auditing data regarding each
conversion. This data may be stored, for example, in the database
212 or provided to one or more of the nodes 220-228. Example
auditing data includes one or more of the "bill to" and "pay to"
amounts (and currency types), as well as the transaction date,
exchange rate information and more as discussed above and
otherwise.
[0060] In a more particular implementation, the transaction
processor 210 further provides reconciliation information for
ameliorating invoice or other discrepancies relating to currency
conversions. Discrepancies may arise, for example, where the
transaction is susceptible to fluctuation in currency exchange
rate. Other discrepancies (or the potential for discrepancies)
arise when timing characteristics of a particular transaction
affect exchange rate; in these instances, the transaction processor
210 records the time used in determining the exchange rate.
[0061] Associated fees with the conversion may be assessed to the
buyer 220 and/or the seller 220 using one or more of a variety of
approaches. These fees may either built into the currency
conversion to the "bill to" amount or separately assessed to the
seller 222 and/or another party and may, e.g., be based on business
rules stored in the database 212.
[0062] Various bases may be used in determining which financial
portion of a particular transaction is to be used in assessing fees
(or, accordingly performing the currency exchange with built-in
fees). For example, in the instance where a transaction uses the
"bill to" amount as the basis for performing a currency conversion,
a particular transaction amount is agreed in terms of the buyer's
currency. Using nodes 220 and 222 respectively as buyer and seller
nodes again, the transaction processor facilitates the billing of
the buyer 220 in the transaction amount ("bill to" amount) in a
first currency. A currency conversion is then made from the "bill
to" currency to the "pay to" currency, with the "pay to" currency
being provided to the seller 222. Fees associated with this
currency conversion may, for example, be built into the conversion
or separately assessed to the seller and/or other party (e.g.,
based on business rules).
[0063] A variety of other transaction-related aspects may be
implemented with the system 200 as discussed above or otherwise. In
some instances, one or more of the user nodes 220-228 include
control input interfaces (e.g., graphic user interfaces) that
communicate with the transaction processor 210, with users at the
nodes being able to provide transaction-related information such as
currency exchange rules. In other instances, the transaction
processor 210 automatically accesses information from the user
nodes for a variety of purposes, such as retrieving currency
exchange rules (e.g., rates, rate sources or exchange sources) or
updating related fields. This interaction between the nodes and the
transaction processor 210 is controlled using, for example,
authorization for access such as password-protected authorization
and others.
[0064] Depending upon the application, the transaction processor
210 assesses fees to one or more of the user nodes 220-228. In some
instances, these fees are built into currency exchange types of
transactions. In other instances, the fees are based upon a
percentage of the amount of payment for a transaction. In still
other instances, the fees involve both a fee based on the amount of
payment for a transaction as well as an amount relating to a
currency conversion. These fees may be applied to one or more of
the parties to the transaction, depending upon the nature of the
transaction, contract agreements with transaction parties and other
considerations. For instance, some transaction implementations
involving buyers and sellers are processed such that the seller
pays all fees associated with a particular transaction. Processing
fees such as these are allocated for the operator of the
transaction processor 210, which may be an entity separate from any
transaction or integral to the transaction, such as a financial
institution related to one of the transaction parties.
[0065] In another example embodiment, the transaction processor 210
is further adapted to grant and control information exchange with
the database 212 as a function of inputs received from the nodes
220-228, such as authorization inputs and transaction-specific
inputs. When users at one of the nodes 220-228 attempt to send
information to or retrieve information from the transaction
processor 210, 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 transaction
processor 210 recognizes.
[0066] The transaction processor 210 is configured and arranged to
outsource bulk currency conversions involving two or more
transactions, according to another example embodiment of the
present invention. For example, where multiple transactions involve
conversion between a first currency and a second currency, the
transaction processor 210 can selectively have a bulk sum of funds
converted, commensurate with the combined sum from the multiple
transactions, from an external financial institution. The
transaction processor 210 can then effect payment and settlement
for the transactions, using the converted funds for all of the
multiple transactions. In some applications, the transaction
processor 210 converts funds for each transaction using a
conversion rate that is higher than the obtained conversion rate
for the bulk conversion, keeping a net difference in funds as a
transaction fee for performing the conversion, for each
transaction. Furthermore, conversion rates for different
transaction parties among the multiple transaction may be
differently applied, for example, as relevant to contracts between
the transaction parties and an operator of the transaction
processor 210. The conversion rates may further be selected, for
each transaction party, from a range of rates deemed acceptable in
a contract with each transaction party. These rates and their
applications are implemented using business rules for each
transaction party, as appropriate, by the transaction processor
210.
[0067] FIG. 3 is a flowchart illustrating an example approach for
automated transaction management involving currency conversion,
according to another example embodiment of the present invention.
Transaction-related information for a pricing function is received
at block 300. This transaction-related information may include, for
example, an electronic order or invoice, or other information
describing pricing or currency characteristics for a particular
transaction or portion of a transaction. The transaction-related
information also includes identification data for at least one
transaction party.
[0068] At block 310, the transaction-related information is
associated with transaction parties using the identification data,
which can include one or more of a variety of information that can
be used to identify one or more transaction parties. For example,
data in an electronic document can be used to identify the source
of the document, which is then identified as one of the transaction
parties. The data may also be used to directly identify a
transaction to which the data applies using, e.g., a transaction ID
number. Further, the data can be used indirectly to identify a
transaction to which it applies, with one or more characteristics
of the transaction being ascertained and associated with a
particular transaction (e.g., where a certain amount of matching
data is used to define a match between the data and a
transaction).
[0069] A pricing term is set using business rules from one or more
parties to the transaction at block 320, and a price for the
transaction is set using the pricing term at block 330. After the
price has been set, a "pay to" price is derived at block 340,
representing the price (in a first currency) to be paid to a seller
transaction party.
[0070] At block 340, business rules from the transaction parties
are used to establish currency conversion rules. The currency
conversion rules may include, for example, one or more of the
above-discussed rules and characteristics associated with currency
conversion such as conversion rate, currency type and exchange
source. At block 350, a currency conversion rate is retrieved from
a rate source, such as a publicly-available rate source, and used
to set a currency conversion rate. At block 360, the derived "pay
to" price is converted to a different currency at a "bill to" price
using the set currency conversion rate, the "bill to" price being
billed to a buyer transaction party.
[0071] After the "bill to" price has been set, payment is processed
at block 370, with the buyer transaction party being billed in the
"bill to" amount and the seller transaction party being paid in the
"pay to" amount. Funds from each separate currency for the "bill
to" and "pay to" amount are typically collected and paid from a
common financial source, which extracts value from the
conversion.
[0072] In some implementations, a payment processing entity
facilitates the receipt and payment of "bill to" and "pay to" funds
by exchanging a debt responsibility with different financial
institutions. For example, where the payment processing entity is
owed funds in the "pay to" currency from a first bank, funds in the
amount of the "pay to" amount can be transferred from the first
bank to the seller transaction party. The payment processing entity
then takes as a receipt the funds from the buyer transaction party
in the "bill to" amount and currency. Similarly, where the payment
processing entity owes finds in the "bill to" currency to a
creditor, payment in the "bill to" amount from the buyer
transaction party (or the associated financial institution) can be
directed to the creditor, with the payment processing entity paying
the seller transaction party the "pay to" amount in the "pay to"
currency.
[0073] At block 380, auditing data is recorded for tracking
purposes relating to the currency conversion and the transaction in
which it is implemented. For instance, the "pay to" and "bill to"
currency and amount are stored, as well as information that can be
used to substantiate a currency conversion rate, such as conversion
data and rate. The conversion date information is further stored as
relevant to a particular time zone, such that transactions with
parties in different time zones can be facilitated. The particular
time zone (as well as other currency conversion parameters) may,
for example, be retrieved with the business rules at block 320.
[0074] The transaction processing approaches discussed above may be
implemented in connection with a variety of types of business
transactions involving the transfer of funds, including those
discussed above and others. In this regard, for general information
regarding transaction processing and for specific information
regarding shipping type transactions and approaches with which the
currency conversion approaches of the present invention may be
implemented, reference may be made to U.S. Pat. No. 5,910,896 to
Hahn-Carlson, which is fully incorporated herein by reference.
[0075] 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.
* * * * *